Beiträge von Andy

Zitat von UEZ

einige Klimmzüge mehr machen muss, um simple Dinge wie z.B. Arraysort oder ein simples GUICreate zu realisieren.

GuiCreate()...für ein KODA vergleichbares Programm werden bei PB knapp hundert Euro aufgerufen...
Generationen von Programmierern tippern sich die Finger mit API Aufrufen wund, aber mal nen Wrapper zu schreiben, DA fehlt es dann!
C/C++ macht es vor, da schaue ich ab und zu mal ins CL-Forum, die haben kein Problem, hunderte von immer gleichen Zeilen BEI JEDEM ERSTELLTEN PROGRAMM einzukloppen, inclusive der darin zwangsläufig vorkommenden Fehler....Profis eben...mal nachgefragt, wieso die diese hunderte Zeilen nicht einfach mit 10 Zeilen wrappern hörst du ausschliesslich Gesabbel:"...warum wir das so machen? Weil wir es können!" Auf die Frage, wieso die "Könner" dann an einfachsten "Fehlern" scheitern und damit dann die Foren fluten folgte ein Ban ...Profis eben...

Da gab es früher mal ein pysikalisches Gesetz...warte mal, gleich hab ich´s...ahjetztja...Leistung ist gleich Arbeit pro Zeit...PRO ZEIT!!! Jetzt weiß ich auch, wieso die alle mit 340 Anschlägen in der Minute schreiben müssen, da darf nur wahnsinnig wenig Zeit ins Schreiben investiert werden, damit die wenige Arbeit kompensiert werden kann
Wenn die ihr Geld mit produktivem Arbeiten statt mit Tippern verdienen müssten, würde die Welt sicher anders aussehen. Alles, was sich damit beschäftigt, das Programmieren an sich zu vereinfachen bzw. zu verbessern, scheint garnicht gewünscht zu sein.

KODA ist auch nur deswegen bei den Autoit-Cracks so verpönt, weil GUI-Erstellung und Management sehr einfach "aus den Fingern laufen". Andere Sprachen würden sich danach alle Finger lecken.

Btw. PureBasic macht einen runden Eindruck, und über die 79€ kann man nicht meckern. Und deren Forum hat einen guten und kompetenten Auftritt.
//EDIT
habe mir die Testversion runtergeladen und werde wohl bestellen, da ist alles dabei, was man sich wünschen kann, und noch mehr^^
//EDIT2
hehe, die haben sogar den FASM mit an Bord, besser kann es garnicht kommen, ich hab mir einige Demoprogramme angeschaut, das ist echt klasse, von sämtlichem GUI-Gedöns bis hin zu D2D,OpenGL, über Datenbanken, alles native und vor allem SIMPEL und EINFACH und VERSTÄNDLICH.

Hi,
_StringBetween() ist mit dem falschen Parameter aufgerufen, wenn du einen Text bearbeiten willst, dann solltest du diesen auch als Parameter verwenden und nicht ein IE-Objekt

Ich würde aber auch dafür das Regex nehmen:

Local $aResult1=StringRegExp($sTxt1,'(?m)^(.*.pdf)',3)
_ArrayDisplay($aResult1, "Result")

Zitat von UEZ

Und bist du mit FB zurecht gekommen? Der Editor (FbEdit) könnte ruhig ein paar Features mehr haben.

Als erstes habe ich mir die Farben von AutoIt-Scite eingestellt
Die IDE ist so, wie ich sie seit Turbo/Power-Basic-Zeiten (ca. 25 Jahre her) kenne. Und seitdem nicht ein Stück weiterentwickelt....
Das in den Schlüsselwörtern fehlende ENDIF habe ich dort nachgetragen Fällt ja auch sonst niemandem auf, IF/ENDIF wird ja so gut wie nie benutzt...

Sofort aufgefallen ist mir die fehlende Console, die ich fürs Debuggen eigentlich bräuchte. Den "Debugger" habe ich mir garnicht erst angeguckt, die Beschreibung für die Benutzung hat mir völlig gereicht . Im Turbobasic war der in der IDE integriert und hatte einwandfrei funktioniert.
Letztendlich habe ich mir mit PRINT und SLEEP ausgeholfen, das schreibt einfach ins nächste geöffnete Fenster, eine Messagebox per shortcut fehlt uswusf... typische Linux-"Programmierer-Umgebung eben", viel Getipper, dass man mit einem Mausklick abhandeln könnte, aber der Programmierer von heute bekommt ja für stundenlanges Getipper Geld und nicht für Vereinfachung/Verbesserung/Innovation!
Der GCC/GAS-Compiler macht das was er soll, und wie gesagt, nicht mal schlecht. Meinen ASM-Code hat der Compiler ohne Overhead integriert, war zu erwarten.
Für 08/15-Programme mag die Umsetzung ausreichen, wenn ich mir den erstellten Code ansehe, dann ist bei aufwendigen Berechnungen noch viel Luft für "Handoptimation".

Insgesamt ein großer Unterschied zum VisualStudio, welches ich jetzt einfach mal als Referenz für ein "Rundumpaket" hernehme. Da ist der gesamte "moderne" Schnickschnack drin, den man braucht oder auch nicht, jedenfalls ist er vorhanden und benutzbar! Der Compiler dort funktioniert auch hervorragend, und man hat den Vorteil, auch für andere Programmiersprachen erstellte Bibliotheken/"UDF´s" einbinden zu können. Ob dieses "Monster" für Quick'n'dirty geeignet ist, muss jeder selbst entscheiden.
Bei einem Basic-Dialekt möchte ich mich nicht mit OOP beschäftigen, andere sehen das anders.

Ja, und da wird die Auswahl eines "Basic"-Compilers mit nutzbarer IDE und "Wohlfühlfaktor" bzgl. reichlich vorhandener und verwendbarer Funktionen schon ziemlich eng.
AutoIt-Compiler?!

//EDIT
http://www.blitzbasic.de scheint Prioritäten auf Grafik zu legen!
http://www.powerbasic.de/html/preisliste.html imho "zu alt"
Für Hardcore-Programmierer ist im MASM-Forum auch ein MASMBasic verfügbar, sehr schnell, wird ständig weiterentwickelt.

Ich doppelposte mal

@UEZ,
hihi, der FB-Compiler ist kein Stück besser wie der AutoIt-Interpreter . Zwar schneller, aber kein Stück besser....
Anbei Script der "handoptimierten" Funktion MandelIter().
Das komplette Programm ist dadurch knapp doppelt so schnell, allerdings wäre noch weit mehr drin, wenn , GENAU WIE IN AUTOIT, diese vermaledeite Doppel-For-To-Schleife nicht für jede einzelne Pixelberechnung einen ziemlich großen Overhead hätte!
Ich schätze mal locker nochmal Faktor 2-3 schneller, wenn man die Doppelschleife per ASM "handcoden" würde. Auch die Codelänge würde sich ca. halbieren.
Jedenfalls habe ich Respekt von den FB-Compilerbauern bekommen, die verwenden schnuckelige Tricks, die ich mir direkt für mein weiteres ASM-Gedöns abgeguckt habe (btw. sind die Tricks gut, die Umsetzung in Code ist nur lausig...aber ich denke, das wird die einen sch**** interessieren )

Wenn man 64Bit verwendet, hat man Register in Hülle und Fülle, da muss man nicht haufenweise Variablen in den Speicher schreiben und daraus lesen.
Kein Wunder, dass viele der hochoptimierten Mathe-Bibliotheken in ASM geschrieben werden....
Bei gut parallelisierbarem Code stinkt auch die schnellste CPU und hochoptimierter Code nicht gegen eine unoptimierte OpenCl-Version an:
Apfelmännchen in OpenCL 15ms auf meiner AMDA6-APU, und da ist das gesamte Speichergeschiebe schon mit drin, die Codelaufzeit auf der 7790-Graka beträgt 1.5ms!
Apfelmännchen in FB 1500ms, Diskussion abgeschlossen. Selbst wenn der Code durch MT 4x schneller wird, und wegen mir noch mal 4x durch AVX rausgeholt wird, ist die Berechnung auf der CPU immer noch 100x langsamer...

'coded by UEZ build 2016-08-04
'idea taken from http://rosettacode.org/wiki/Mandelbrot_set#C.23 / JS version


#include "windows.bi"
#include "fbgfx.bi"
Using FB


Declare Function mandelIter(cx As Single, cy As Single, maxIter As ULong) As ULong
Declare Function mandelIter_asm(cx As Single, cy As Single, maxIter As ULong) As ULong
Declare Sub Mandelbrot(xmin As Single, xmax As Single, ymin As Single, ymax As Single, iterations As ULong, iDisplayFrequency As ULong = 100)


Dim As Integer sW, sH
ScreenInfo(sW, sH)


Dim Shared As ULong iW, iH


iW = 1000 'Int(sW * 0.95)
iH = 600 'Int(sH * 0.90)


ScreenControl FB.SET_DRIVER_NAME, "GDI"
ScreenRes iW, iH, 24


Dim As String sTitle = "GDI Mandelbrot"
WindowTitle sTitle


Dim as HWND hHWND
ScreenControl(FB.GET_WINDOW_HANDLE, Cast(Integer, hHWND))


Dim Shared As HDC hDC
hDC = GetDC(hHWND)


Dim As BITMAPV5HEADER tBIV5HDR
tBIV5HDR.bV5Size = SizeOf(BITMAPV5HEADER)
tBIV5HDR.bV5Width = iW
tBIV5HDR.bV5Height = -iH
tBIV5HDR.bV5Planes = 1
tBIV5HDR.bV5BitCount = 32
tBIV5HDR.bV5Compression = BI_BITFIELDS
tBIV5HDR.bV5AlphaMask = &hFF000000
tBIV5HDR.bV5RedMask = 	&h00FF0000
tBIV5HDR.bV5GreenMask = &h0000FF00
tBIV5HDR.bV5BlueMask = 	&h000000FF


Dim Shared As ULong Ptr aBits
Dim As HBitmap hBitmapGDI
Dim Shared As HDC hGfxDC


hBitmapGDI = CreateDIBSection(hDC, @tBIV5HDR, DIB_RGB_COLORS, @aBits, NULL, NULL)
hGfxDC = CreateCompatibleDC(hDC)
Var hObjOld = SelectObject(hGfxDC, hBitmapGDI)


Dim evt As EVENT
Dim As ULong iFPS = 0, i, iMax = iW * iH - 1 , iX, iY, iARGB




Dim As Double fTimer, fEnd


fTimer = Timer
Mandelbrot(-2, 1, -1, 1, 1000, 100)
fEnd = Timer - fTimer
WindowTitle sTitle  & " / Took " & fEnd & " seconds to render."


Do
	If (ScreenEvent(@evt)) Then
		Select Case evt.Type 
			Case SC_ESCAPE, EVENT_WINDOW_CLOSE
				SelectObject(hGfxDC, hObjOld)
				ReleaseDC(hHWND, hDC)
				DeleteDC(hGfxDC)
				DeleteObject(hBitmapGDI)
				Exit Do
		End Select
	EndIf
	Sleep(60)
Loop


Sub Mandelbrot(xmin As Single, xmax As Single, ymin As Single, ymax As Single, iterations As ULong, iDisplayFrequency As ULong = 100)
	Dim As ULong i, ppos
	Dim As Double c, x, y
	Dim As ULong iX, iY
	For iY = 0 To iH - 1
		For iX = 0 To iW - 1


			x = xmin + (xmax - xmin) * iX / (iW - 1)
			y = ymin + (ymax - ymin) * iY / (iH - 1)
			i = mandelIter_asm(x, y, iterations)
			ppos = (iW * iY + iX)
			If (i > iterations) Then
				aBits[ppos] = &hFF000000
			Else
				c = 3 * Log(i) / Log(iterations - 1.0)
				If (c < 1) Then
					aBits[ppos] = &hFF000000 + (Int(255 * c) Shl 16)
				ElseIf ( c < 2 ) Then
					aBits[ppos] = &hFF000000 + (255 Shl 16) + (Int(255 * (c - 1)) Shl 8) 
				Else
					aBits[ppos] = &hFFFFFF00 + (Int(255 * (c - 2)))
				EndIf
			EndIf
		Next
		If iY Mod iDisplayFrequency = 0 Then BitBlt(hDC, 0, 0, iW, iH, hGfxDC, 0, 0, SRCCOPY)
	Next
	BitBlt(hDC, 0, 0, iW, iH, hGfxDC, 0, 0, SRCCOPY)
End Sub


function mandelIter_asm( var_cx As Single, var_cy As Single, maxIter As ULong) As ULong
    asm
        mov eax, [maxIter]      'maxiter
        mov ecx, eax            'i
        mov edx,0x40800000      '4.0 single
        movd xmm7,edx           '0,0,0,4.0
        movd xmm4,[var_cy]      '0,0,0,cy
        pslldq xmm4,4           '0,0,cy,0
        movd xmm5,[var_cx]      '0,0,0,cx
        addps xmm4,xmm5         '0,0,cy,cx
        xorps xmm0,xmm0         '-,-,y,x    integer0=float0 ^^
  '      .align 8               'code aligning
        label1:
        pshufd xmm1,xmm0,0xD0   'xmm1 -,y,x,x
        pshufd xmm2,xmm0,0xD4   'xmm2 -,y,y,x
        mulps xmm1,xmm2         'xmm1 -,yy,xy,xx
        pshufd xmm2,xmm1,0xF6   'xmm2 -,-,xy,yy
        movups xmm3,xmm2        'xmm3 -,-,xy,yy
        addps xmm3,xmm1         'xmm3 -,-,-,xx+yy
        comiss xmm3,xmm7        'ist xx+yy<4?
        setb bl                 'wenn below, bl=1 dann weiter
        test bl,bl              'bl=0?
        jz labelend             'wenn null, dann raus!
        addsubps xmm1,xmm2      'xmm1 -,-,xy+xy,xx-yy
        addps xmm1,xmm4         'xmm1 -,-,xy+xy+cy,xx-yy+cx
        movups xmm0,xmm1        'xmm0 -,-,y,x
        dec ecx                 'i=i-1 ist i>0?
        jnz label1              'wenn nicht null, dann weiter 
        labelend:
        sub eax,ecx             'maxiter - i
        mov [function], eax
        end asm
end function


Function mandelIter(cx As Single, cy As Single, maxIter As ULong) As ULong
	Dim As Single x = 0.0, y, xx, yy, xy 
	Dim As ULong i = maxIter
	While (xx + yy < 4 And i > 0)
		xy = x * y
		xx = x * x
		yy = y * y
		x = xx - yy + cx
		y = xy + xy + cy
		i -= 1
	Wend
	Return maxIter - i
End Function

Zitat von UEZ

Da frage ich mich ernsthaft, warum ich noch in AutoIt "Brotlose Kunst" coden soll!

Ich zitiere mich mal selbst:

Zitat von Andy

Ich bin immer noch davon überzeugt, dass AutoIt für 99% aller Aufgaben gut geeignet und schnell genug ist. Leider zieht das eine Prozent aus o.g. Gründen gute Leute ab.

Na gut, für dich als "Künstler der brotlosen Künste" liegt der Anteil bei vielleicht 50% "Eignung" für deine Vorhaben. Das sind immer noch NUR 50%. Also absolut kein Grund, weiter bei AutoIt zu bleiben. Jedenfalls in diesem Bereich....
Was die Frage aufkommen lässt, wieso jemand, der sowieso die Vorteile einer anderen Programmiersprache ausnutzt, nicht gleich komplett wechseln soll?!
Ich jedenfalls arbeite nur noch just for Fun mit AutoIt. Und dann, wenn ich "Fernsteuerungs- und Datentransfereigenschaften" nutzen muss. Und auch DAS ist selten genug...
Das bissl GUI-Gedöns (alles rund um das Window-Info-Tool) ist schnell nach FB oder auch anderen Sprachen gewrappert, dann hätte AutoIt KEINEN Vorteil gegenüber anderen Basic-Dialekten mehr für mich.

Hier im Forum hält mich nur noch die Nostalgie, da viele der fitten Leute bereits abgewandert sind. Wenn die ein- bis zwei Handvoll User, die ich sehr schätze, sich weiter so rar machen, werde ich mir auch (zwangsläufig) andere Betätigungsfelder suchen, bzw. mit diesen Usern mitwandern....

Zitat von UEZ

da FB relativ einfach zu lernen ist und man damit schnelle Dinge "zaubern" kann.

"schnelle Dinge zaubern"
Ok,da gehe ich mit! Einfach zu lernen, für das meiste schnell genug....SO sollte AutoIt sein, oder ist es das nicht sogar?
Gut zu parallelisierende Algorithmen sind zwar immer noch 100x schneller per OpenCL/CUDA, aber wenn man SOOO schnell gar nicht braucht ist die damit erreichte Beschleunigung überflüssig.

Battle 3. Teil kann kommen....

Zitat von UEZ

Function mandelIter:

Wie schon in anderen "Sichtungen" festgestellt, ist das FB-compilat wirklich "schön". Nicht gelungen, aber "schön"
SSE wird zwar nur mit "einem" 32-Bitregister (statt der verfügbaren 4) benutzt, allerdings sind die SSE-Befehle generell schneller. Handoptimiert schätze ich mal die mögliche Beschleunigung locker auf Faktor 2-3, weil ich statt, wie der Compiler, die Parameter auch in die SSE-Register schreiben würde statt, wie der Compiler, mir vom Stack einige Bytes an RAM zu genehmigen. Was btw. aber eine sehr "schicke" Lösung für einen Compiler ist, da habe ich schon weit üblere Varianten gesehen...
Hat man das erst einmal erkannt, lässt sich auch der Compilercode um Faktor 2-3 beschleunigen, statt des "Basic"-Codes für den inner Loop nutzt man den Inline Assembler!

Wenn man aber Inline Assembler nutzt, dann kann man ja gleich AssembleIt() nutzen und braucht kein Freebasic

Nichtsdestotrotz ist diese Lösung des FB-Compilers/Assemblers aber Faktor 100 langsamer als bspw. ein (auch per AutoIt ansprechbarer) OpenCL-Code, welcher auf einer Grafikkarte (alternativ CPU) läuft. Und OpenCL wiederum ist "simpler" C-Code, auf den hunderten Prozessoren einer 80€- Graka ausgeführt 100x schneller als auf einer schnarchlahmen 1000€-Oktacore-CPU!

Wenn ich jetzt wirklich bitterböse wäre, dann würde ich folgendes Fazit aus dem Battle "AutoIt vs. FreeBasic" ziehen.
Die Faktoren beziehen sich jedes Mal auf die vorherige Position:
AutoIt-Code lahm...Faktor 1
FB-Compiler schnell(er) Faktor 100
FB-Compiler handoptimiert Inline-ASM Faktor 3
AutoIt AssembleIt Faktor 1
AutoIt OpenCL Faktor 100-1000 je nach Grafikkarte (ja, 100 bis 1000 (tausend) mal schneller als der FB-(und übrigens auch jeder andere CPU-)Compiler! )

OpenCL-Version, Infos dazu hier
OpenCl_Apfel_Forumversion.zip

Hi,
kein Wunder, da genau der "langsame" DllStructSetData() in einem ewig langen Loop wieder verwendet wurde.
Übrigens ist es bei mir so, dass beim FB-Programm der Fensterinhalt schwarz wird, sobald ich das Fenster nur zu einem kleinen Teil über den Bildschirmrand schiebe...

Könntest du die Funktion Mandeliter() solo in eine Dll packen bzw den gesamten For $iY = 0 To $iH - 1For $iX = 0 To $iW - 1-loop.
Ich würde da gerne mal mit dem Disassembler drübergucken, FB produziert imho einen "schönen" Code....

Auch im Hinblick auf auf weitere "Battles" hätte ich gerne Anwendungen gesehen, welche von den bei FB und AutoIt gleich schnell ausgeführten API-Funktionen (ist das so?) abhängig sind.
BugFix hatte mich mal vor Jahren auf "schnelle(re)" Arrayfunktionen angesetzt, ich habe damals ein Script geschrieben, welches bestehenden AutoIt-"Array"-Code komplett auf DllStruct-Code umschrieb. Der Geschwindigkeitsvorteil war nicht sonderlich groß, wobei wir wieder beim Thema DllStructSet/GetData wären...
Logischerweise macht das nur Sinn, wenn auch die Datentypen "gleich" und schön zu verarbeiten sind.
In FB sollten imho auch Arrayfunktionen (Arraysort bspw) wesentlich schneller arbeiten.

Hat jemand noch weitere Beispiele für "langsamen" AutoItcode? Also so langsam, dass das Script/Anwendung unbenutzbar wird? Mich interessieren Anwendungen aus der Praxis, die aufgrund der Geschwindigkeit von AutoIt dessen Verwendung ausschließen.

Zitat von Xorianator

Dann müssen sie uns (mich darfst du schon Mal dazu nehmen) per se doch nicht finden, es reicht ja in der Nähe zu stehen, oder habe ich was falsch verstanden?

Naja, stell dir vor, du stehst irgendwo in der Halle und "sendest". Bei geschätzten mindestens 50 bis 100 Leuten in der Halle, welche eine, wenn auch relativ ungenaue "Entfernung" bzw. eigentlich die Signalstärke feststellen.
Von den anderen 500 Leuten mal abgesehen, die zu diesem Zeitpunkt bereits versuchen, den ESP zu hacken
Was glaubst du, wie schnell die Typen dort ein Programm schreiben in dem sich jeder "Sucher" mit Standort (relativ zur Halle) und Signalstärke einträgt. Peilung gemacht, plusminus 2-3 Meter Genauigkeit, und du landest von der Kamera eingefangen auf der Großbildleinwand
Mal angenommen du wirst gefunden und angesprochen, und es blinken irgendwelche vom Webinterface angestoßenen LED´s an deinen Klamotten welche einen "Code" darstellen, wegen mir 8 Bit Ascii. Jeder Träger eines ESP (auch draußen im Freien und auf dem Parkplatz im Auto können ja welche sein ^^) kann also einen oder mehrere Buchstaben "blinken".
Diese Buchstaben zusammen ergeben ein Passwort, welches auf dem Webinterface eingeloggt ein "Bild.jpg" freischaltet. In diesem Bild ist per Steganografie ein weiteres Passwort "versteckt", dieses im Webinterface eingegeben lässt die LED´s/Bildschirm/abgespielter Sound des "Trägers" des ESP wieder aktivieren uswusf....
....
....
.... bis letztendlich nach einigen Stunden Rätseln wir alle auf der Bühne nebeneinander stehen, und unsere "blinkenden" T-shirts/oderwasauchimmer einen "Hackerschriftzug" formen

//EDIT
Ich hatte diesen Thread eigentlich als Konversation für einige Mitglieder dieses Forums vorgesehen, leider ist die maximale Anzahl an Konversations-Teilnehmern auf 10 begrenzt, und ich mochte einige nicht aus der Gruppe ausschließen!
GGf. gibt es jemanden, der die Anzahl der Teilnehmer einer Konversation auf ca. 20 Teilnehmer erhöhen kann.

Hi zusammen,

ich habe seit einigen Wochen mehrere ESP8266-12E im Einatz und muß sagen, ich bin begeistert.
Betrieben werden diese über ESP-Basic, einmal geflashed braucht man nur noch 3.3V als Spannung und sämtliche Programmiererei (in Basic^^) erfolgt per Browser und WLAN.

Da ich schon einige Experimente mit diversen Sensoren, aber auch mit AutoIt und dem Datenaustausch des auf dem ESP laufenden Webservers hatte, kam mir folgende Idee.

Auf der kommenden Revision treffen sich die Hacker der Welt/Europa, und "Spiele" mögen die meisten ja auch
Ich hoffe, "wir" aus dem AutoItforum werden auf der Revision wieder vertreten sein. Da man mit AutoIt an sich dort nicht sonderlich viel reißen kann, hatte ich mir etwas anderes vorgestellt:

Ich plane eine "Schnitzeljagt" für alle Revision-Teilnehmer, wobei jeder von uns "AutoIt´lern" einen/mehrere ESP8266 trägt, auf dessen Webserver(n) eine Anwendung läuft. Ziel soll es sein, alle "ESP"-Träger per Triangulation bzw. andern Methoden zu finden, bzw. die auf dem Webserver "versteckten" Anwendungen/Hinweise zu finden.
Der Zugang zum ESP ist sehr simpel über jedes Webinterface möglich, d.h. sämtliche auf der Revision vorhandenen Geräte bekommen ein/mehrere "offene" WLAN angezeigt.
Auf den ESP´s, welche als voneinander völlig unabhängige WiFi Stationen laufen, hat der User die Möglichkeiten interaktiv Aktionen anzustoßen, LED´s blinken lassen uvm.
Hat man alle ESP-Träger gefunden und deren preisgegebene Informationen zum richtigen "Passwort" zusammengesetzt, bekommt man Zugang zu weiteren "Rätseln"....

Und hier kommt Ihr alle ins Spiel
Lasst euch was einfallen!

Es werden sowohl Software, als auch Hardware-Ideen gesucht, welche man bei diesem Projekt verwenden kann. Der ESP ist ca. 3x2cm groß und soll/kann über eine "Halskette" als Amulett getragen werden können, das eventuelle "Bling-Bling" als LED´s/Bildschirm/Sensoren/wasauchimmer soll an den Kleidern getragen werden.
Rudimentär hatte ich neulich so etwas ähnliches auf dem Abschlussball meiner Tochter verbaut, einen ESP als "Amulett", und einige 3-Farben-LED´s im Haarschmuck, die man von jedem Handy aus interaktiv blinken lassen konnte.
Die Kiddies haben sich einfach in das offene WLAN eingebucht und konnten auf der "Website" 192.168.4.1 per Buttons ihr individuelles LED-Geblinke in den Haaren und am Amulett/ESP meiner Tochter anstoßen. In einem Eingabefeld gab es noch die Möglichkeit, kurze Texte und einen Namen zu hinterlassen...Ihr könnt euch nicht ansatzweise vorstellen, was dort abging
Letztendlich haben nach ca. 2h die beiden Stromversorgungs-AAA-Akkus aufgegeben Papa hatte natürlich noch Ersatzbatterien dabei, aber im Sinne der Beibehaltung der öffentlichen Ordnung habe ich dann doch abgebrochen

Wer Lust am Experimentieren hat, mit ca. 5 bis 10€ für alle benötigten Bauteile (ESP8266, USB-auf-3.3V-Spannungswandler, diverses "Hühnerfutter" LED´s,Widerstände etc.) ist man dabei.
Aber viel eher werden anspruchsvolle Ideen und Rätsel gesucht, welche auch gestandenen Hackern ein bissl Gehirnschmalz abverlangen. Da die auf der Revision versammelte Community untereinander sehr gut vernetzt ist, werden sämtliche Ergebnisse/Hinweise sicher schnell weitergegeben.
Musik und Bilderrätsel oder auch Steganografie sind ein MUSS
Auf den ESP´s ist sowohl JS als auch HTML lauffähig.

Ich hoffe auf feedback....

Zitat von AspirinJunkie

Wenn ein unabhängiger eine andere Implementierung erstellt haben die AutoIt-Devs schlicht nichts mehr damit zu tun. Warum auch?

Das stimmt, wenn allerdings ein Mitglied des "inner circle" solch ein Projekt in der Schublade hat, dann wird es spannend!

Wenn man als Projektleiter/Manager merkt, dass jemand im Team in bestimmten Bereichen überragende Fähigkeiten besitzt, dann gehört dieser Jemand zum Wohle des Projekts gefördert und nicht abgesägt/gebremst! Wenn im Laufe der Zeit mehrere Leute mit überragenden Fähigkeiten das Team verlassen, dann hat das Gründe. "Es darf keine anderen Götter neben mir geben.." ist einer davon!

BTT, wann kommt der 2. Teil von "AutoIt vs FreeBasic"

Zitat von Xorianator

So treten wir nie auf der Revision auf

Ich hab ein echt heißes Eisen im Feuer, da werden wir die Revision mal richtig aufmischen
Das einzige, was AutoIt damit zu tun haben wird ist der Aufdruck auf meinem T-Shirt . Das werde ich wohl aus Pietätsgründen tragen und wg. der "guten alten Zeiten".

Zitat von AspirinJunkie

Ich bin ehrlich gesagt erstaunt dass hier einige mal schnell einen Compiler von den Devs fordern als wärs das simpelste auf der Welt.

Ich bin hingegen garnicht erstaunt, daß der imho schon von einer Entwicklerin vor Jahren wenigstens als Prototyp lauffähige Compiler (ja, und das war schon zu Valiks Zeiten Thema!) in ihrer Schublade liegt.

Und "gefordert" wird von mir nichts!

Mal von sämtlichen technischen Hintergründen abgesehen ist es aber die eine Sache, unisono "gibt es nicht, und wird es nie geben..." von Entwicklerseite zu hören oder ein "...muss niemand Arbeit investieren, wir haben etwas am köcheln, dauert ggf. noch einige Jahre, gibt höhere Prioritäten!".

Es stellt sich nicht die Frage des Könnens (oder doch?!) sondern die des Wollens. Oder will man nicht weil man nicht kann? Dann steht wieder die Frage im Raum wieso man nicht jemanden die Arbeit machen lässt, der es kann....

Zitat von AspirinJunkie

Am Ende reicht es aber dennoch nicht das nur viele fordern sondern das einer auch mal aufsteht und loslegt.

Ich spinne jetzt mal bissl rum und offenbare, dass du morgen einen AutoIt-Compiler, und wenn auch nur als "Krücke", released. Spätestens übermorgen werden im "blauen" Forum HUNDERTE neuer Threads erstellt werden, und ich verwette meinen rechten Arm, JEDER davon wird abgeschmettert mit dem Hinweis "..ist nicht von uns, haben wir nix mit zu tun, wende dich an den Entwickler hier gibts keine Unterstützung..."

Ich bin immer noch davon überzeugt, dass AutoIt für 99% aller Aufgaben gut geeignet und schnell genug ist. Leider zieht das eine Prozent aus o.g. Gründen gute Leute ab. Mal schnell "quick´n´dirty" mit einer Handvoll "Basic-ähnlicher" Zeilen eine Lösung ausarbeiten, dabei ist AutoIt imho ungeschlagen. Im professionellen Umfeld nutze ich dazu die 3.3.8.1 , da weiß ich was ich habe und alles was ich will funktioniert auch.

Zitat von Xorianator

Weil AutoIt für so etwas nun mal nicht erfunden wurde.

Das Rad wurde auch nicht dafür erfunden, um mit 200Km/h über die Autobahn zu brettern, sondern um mit Esel-Geschwindigkeit über den Acker zu gondeln...

Zitat von Xorianator

dann hast du 2 Möglichkeiten: 1. Du stellst es ein, oder 2. Du veränderst dein Produkt, damit du nicht dicht machst.

Und wer bitteschön hindert die AutoIt-Entscheider daran, einen Compiler zu releasen der in der Schublade liegt? Ich sags dir, "der kurze Bippes"!!! Denn sämtliche Innovationen der letzten Jahre kommen aus der Ecke der progressiven Entwickler, und das ist für die alteingesessenen schon übel genug...deshalb werden diese progressiven Entwickler auch reihenweise abgesägt. Wer aufmuckt, fliegt raus, so läuft der Hase.
Ein Compiler würde das komplette Weltbild (seitens DEV´s) auf den Kopf stellen, das ist definitiv Fakt! Und dafür soll die Community dann auch noch Beifall spenden?!
Als ob die Community nicht selbst wüßte woher die Innovationen kommen/kamen...

Und eins noch, so wie ich meine Pappenheimer kenne, releasen die ganz ohne viel tamtam irgendwann doch den Compiler....und DANN müssen sich die DEV´s fragen lassen, wieso das Ding nicht aus deren Schublade kam. Auf DIE Antwort wirst du so lange warten können wie auf einige der "unbequemen" Antworten in diversen Tickets.

Es gibt eine sehr simple Lösung, welche ich bei Assembleit2_64 eingesetzt hatte, um 32-Bit-Programme mit 64-Bit-Programmen kommunizieren zu lassen.

Das Programm A erstellt ein (unsichtbares) Edit- oder Labelcontrol und schreibt dort seine Daten rein.
Programm B holt sich über das Fensterhandle und ControlGetText den Inhalt dieses Controls.

Für ein einfaches, d.h. zeitunkritisches Script reicht es, wenn Programm B sich per AdlibRegister bspw. alle 10/100/1000 Millisekunden den Inhalt des Controls von Programm A ausliest. Sobald der Inhalt ausgelesen ist, schreibt Programm B einen Leerstring in das Control. Heißt also, solange das Control "leer" ist, gibt es auch keine neuen Daten.
Wenn Programm A neue Daten zur Verfügung hat, werden diese ins Control geschrieben.

Benötigt in beiden Programmen nur eine Handvoll Zeilen.

Zitat von UEZ

was bei annähernd gleichem Code Aufbaus für ein extremer Unterschied sein kann

@chip, ich sag`s mal für die "nichtverstehenWOLLER" deutlich: Ein AutoIt-Compiler ist längstens überfällig. Allerdings wurden/werden sämtliche Ansätze dorthin rigoros abgeblockt. So weit, das einige DEV´s lieber das Handtuch werfen, statt weiter "herumzufrickeln". Eins steht fest wie das Amen in der Kirche, der "Compiler-Fork" wäre sofort nach Bekanntgabe massiv unterstützt und gehyped worden. So massiv, dass die "classic"-DEV´s nur noch hinterherschauen...und sich letztendlich von der Community in eine Richtung drücken ließen, die seitens Heeresleitung SO ganz und gar nicht gewünscht ist!

Zitat von chip

was für ein Sinn hat ein Vergleich zwischen Äpfeln (Compiler) und Birnen (Interpreter)

Es stellt sich die Frage, wieso jemand, der fit in AutoIt ist, lieber/besser andere Programmiersprachen nutzt bzw. nutzen MUSS!?
Und wie ich schon sagte, UEZ´s Beispiel ist geschönt, weil AutoIt viel zu gut dabei wegkommt.

Wir haben hier im Forum einige TOP-Leute an andere Programmiersprachen genau aus diesem Grund verloren. Und definitiv nicht, weil man heutzutage ohne plusplus-Gedöns keine guten Programme schreiben kann.

Zitat von UEZ

an Multi Threading hatte ich auch schon gedacht, aber das Memory Management ist nicht immer ganz trivial

Die Komplexität des Memory-Management und explizit der Zugriff auf "shared" Memory hängt mehr vom Können des Programmierers als von den Möglichkeiten der Programmiersprache ab! Multi-Threading ist supersimpel, solange threadsafe Funktionen benutzt werden. Ansonsten wird es zäh...
Wobei man sich fragen muss, wieso Programme, welche für Multi(=viele, d.h. mehr als die Anzahl von CPU-Kernen)-Threading geeignet sind, nicht direkt per CUDA/OpenCL geschrieben werden. Da übernimmt der Compiler komplett sämtliches Thread-Management und auch das Memory-gefrickel. Und wählt selbst das geeignete Device, entweder CPU oder GPU...

Was natürlich die Frage aufwirft, wieso nicht per AutoIt und OpenCL zu arbeiten, statt mit CompilerBasic und einem lächerlichen Thread

Btw. wird die maximale Anzahl FPS sowieso durch den Sleep() begrenzt.

Hi,
ich finde, AutoIt sieht im Vergleich garnicht mal so schlecht aus...nur 25 mal langsamer als eine Compilersprache ist imho sogar nur deshalb zu erreichen, weil fast ausschließlich "billige" Berechnungen durchgeführt werden, bzw. weil die Ausführungsgeschwindigkeit der "teuren" Funktionen (in diesem Fall das Blitten) als API-Aufruf(e) sowohl beim Compiler als auch bei AutoIt die gleiche Laufzeit benötigen.
Der viel realistischere Faktor 1000 in der Laufzeit ist schon oft von entsprechenden C(++)-Dll´s oder auch ASM-Code gezeigt worden.

Viel wichtiger, und das auch im Hinblick auf "Optimierungen" (übrigens sowohl des Compiler- als auch des AutoItcodes!!!) wäre mal ein Vergleich der lokalen Laufzeiten, also profiling. Die Erfahrung zeigt, dass sich durch diese Analysen und die Umsetzung von Verbesserungen im Code wesentliche Beschleunigungen erreichen lassen.

Es wäre anzunehmen, dass in AutoIt die Funktion MoveParticles() die hauptsächliche Leistung benötigt, dem ist aber garnicht so! Diese Funktion ausgeklammert liefert AutoIt die gleichen FPS!
Der For $i = 1 To $iParticles - Loop ist die Ursache des AutoIt-Elends. Jede in diesem Loop ausgeführte "Funktion", und sei es nur ein simples "INT()" lässt die Leistung zusammenbrechen!

For $i = 1 To $iParticles
			MoveParticles(MouseGetPos(0), MouseGetPos(1), $i)
			$iX = Int($tParticles.x(($i)))
			$iY = Int($tParticles.y(($i))) * $iW
			;$tBitmap.px(($iY + $iX)) = $tParticles.color(($i)) ;write directly to the bitmap (one pixel)
		Next

das unsäglich langsame DllstructSetData(), hier als $tBitmap.px(($iY + $iX)), nervt mich schon seit Jahren und war auch der Grund für die Verwendung kleiner ASM-Programme

https://www.autoitscript.com/forum/topic/13…ecode-zlib-pdf/
sollte dich weiterbringen

Hi,
um mit Acrobat-Objekten arbeiten zu können, muss die Vollversion des Acrobat-Readers installiert sein!

Ich habe aber noch eine andere Möglichkeit gefunden, mit dem kostenlosen Foxit-Reader. Dieser besitzt die Möglichkeit, Formulardaten zu importieren. Um diese zu importierende Formulardatei zu erstellen, einfach die vorliegende PDF im Foxit öffnen und im Reiter "FORMULAR" , "Exportieren", "In eine neue Datei" auswählen.
Die so erstellte Datei, ich nenne sie mal Vorlage.fdf , ist eine einfache Textdatei, die Feldinhalte sind im Klartext zu lesen/schreiben. Achtung, Geldbetrag wird in meiner Version nicht richtig exportiert (eine Ziffer fehlt), ich würde daher 9999.99 einsetzen.

Ablauf also folgender:
- Vorlage als Textdatei öffnen, Felder "ausfüllen" (Feldnamen mit gewünschten Inhalten im Text ersetzen), Vorlage als "Ausfuellen.fdf" speichern.
- Foxit mit Vorlage öffnen, und die Formulardaten "Ausfuellen.fdf" importieren. PDF speichern, ferdsch!

Der Ablauf sollte entweder mit AutoIt zu automatisieren sein, ggf. gibt es auch Commandline-Möglichkeiten, für meine Version habe ich keine gefunden...

Hi,
wieso ein RegEx, dass der User sowieso nicht nachvollziehen kann?

@Mojo, schau mal nach Stringbetween() in der Hilfe!
Da du einen String bearbeiten willst, sollten sämtliche Stringfunktionen der erste Anlaufpunkt in der Hilfe sein. Kannst du beschreiben, wie du dort gesucht hast und wieso du die Funktion nicht gefunden hast?

#include <String.au3>
#include <Array.au3>


$text = "eMail-Delay=6.67 OK - Login and Email successfull in 8 seconds, eMail-Delay 6.67 seconds"


$delay1 = _StringBetween($text, "Delay=", " OK ")     ;findet erstes Vorkommen
MsgBox(0, 0, $delay1[0])


$delay2 = _StringBetween($text, "Delay", " seconds")  ;findet zweites Vorkommen?!
MsgBox(0, 0, $delay2[0] & @CRLF & "uuuupppsss!?")




MsgBox(0, 0, $delay2[1] & @CRLF & "so gehts...")


_ArrayDisplay($delay2)                                ;alle Vorkommen zwischen "Delay" und " seconds"