| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 557
Wohnort: Jüterbog
|
 Verfasst am: 27.01.2012, 21:45 Titel: |
 |
|
.. es wird ein wenig OT 
Wollte lediglich darauf hinweisen, das eine in der Referenz beschriebene Eigenschaft von GET so (mit Strings) nicht nutzbar ist.
Mutton |
|
| Nach oben |
|
 |
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 28.01.2012, 12:37 Titel: |
|
|
| Flo hat Folgendes geschrieben: | ausserdem will man nicht types GETen, genausowenig wie man structs in C read() en will. stichwort big/little endian und ebn padding
|
Aha, du liest also lieber Integers byte für byte ein und stückelst die dann wieder in der korrekten Endianness zusammen?
| Code: |
#pragma pack(1)
struct Foo
{
int16_t foo;
int32_t bar;
}
#pragma pack()
...
Foo bar;
// bar einlesen...
bar.foo = LittleEndian16(foo);
bar.bar = LittleEndian32(foo);
|
Natürlich alles nur schematisch dargestellt, aber was ist jetzt das Problem dabei?
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4531
Wohnort: ~/
|
| Verfasst am: 28.01.2012, 13:39 Titel: |
|
|
@Muttonhead: GET lässt sich schon auf die angegebene Weise Nutzen; die darunter angegebene Berechnungsformel ist aber nicht korrekt. Mit
| Code: | type ChunkDescriptor field=1
chunkID as string*4
chunksize as integer
rifftype as string*4
end type |
bekommst du die UDT-Länge 14, was mit MODs Erklärung zum angehängten CHR(0) übereinstimmt. Die überschüssigen Byte kommen bei dir vom Padding 4. Wir werden die Erklärung auf jeden Fall in der Referenz einbauen.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 557
Wohnort: Jüterbog
|
| Verfasst am: 28.01.2012, 15:23 Titel: |
|
|
@nemored: um mehr gehts mir ja auch nicht, auch wenn ich es nicht explizit betont habe...
Trotzdem scheint mit das Verhalten unlogisch, warum eine gleich definierte Stringvariable(mit *x) verpackt in ein UDT (mit field=1) nun auf einmal ein Byte mehr aus der Datei liest...
btw: hab mein Problem nun ohne udt gelöst  |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1872
Wohnort: D59192
|
| Verfasst am: 28.01.2012, 16:20 Titel: |
|
|
Hi,
es geht auch mit UDT in anderer Definition
| Code: | Type ChunkDescriptor
chunkID As Integer
chunksize As Integer
rifftype As Integer
End Type
Dim riffhead As ChunkDescriptor
riffhead.chunkID = Cvi("RIFF")
riffhead.rifftype = Cvi("WAVE")
? Len(riffhead),"&h";Hex(riffhead.chunkID),"&h";Hex(riffhead.rifftype)
? ,Mki(riffhead.chunkID),Mki(riffhead.rifftype)
Sleep |
Hier wird kein String definiert damit keine zusätzlichen CHR(0) die Udtgröße verändern.
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 557
Wohnort: Jüterbog
|
| Verfasst am: 28.01.2012, 16:35 Titel: |
|
|
Jahhhh Volta großes Kino
Fühlst du dich nach sowas eigentlich besser? 
Gefällt mir wirklich gut!!! |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1872
Wohnort: D59192
|
| Verfasst am: 28.01.2012, 18:19 Titel: |
|
|
solltest du diese einfache Schreibweise mal leid sein
| Code: | | riffhead.chunkID = *Cast(Integer Ptr, StrPtr("RIFF")) |
geht auch
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
Lou Ziffer
Anmeldungsdatum: 12.01.2012
Beiträge: 7
|
| Verfasst am: 14.02.2012, 20:56 Titel: |
|
|
| Zitat: | | Trotzdem scheint mit das Verhalten unlogisch, warum eine gleich definierte Stringvariable(mit *x) verpackt in ein UDT (mit field=1) nun auf einmal ein Byte mehr aus der Datei liest... |
Genau das gleiche passiert auch mit Arrays. Wahrscheinlich sind Strings intern auch nur Arrays und es ist der gleiche Bug. Ich wollte Daten übers Netzwerk senden und dachte mir ich mach das einfach mit einem UDT.
Falsch gedacht. Die Arrays sind dann immer genau ein Element zu groß.
| Code: |
TYPE testUDT Field = 1
array1(4) as byte
END TYPE
print len(testUDT)
|
gibt 5 aus
| Code: |
TYPE testUDT Field = 1
array1(4) as integer
END TYPE
print len(testUDT)
|
gibt 20 aus
Kann man die einfach entsprechend kleiner machen oder ist zu erwarten das dieses seltsame Verhalten ev. noch korrigiert wird? |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 14.02.2012, 21:07 Titel: |
|
|
Nicht ganz:
1) Strings sind intern keine Arrays sondern eine Art UDT
2) ein array(4) erzeugt anders als in C nicht Elemente von 0 bis 3, sondern von 0 bis 4, also 5 Elemente. Möchte man das umgehen, muss man eben beide Grenzen angeben: array(0 to 3) bzw. array(1 to 4)
Beides sind weder seltsames Verhalten noch Bugs, es ist genau so gewollt und bekannt. Zudem sollte es in der Referenz beschrieben sein. |
|
| Nach oben |
|
|
Lou Ziffer
Anmeldungsdatum: 12.01.2012
Beiträge: 7
|
| Verfasst am: 14.02.2012, 21:28 Titel: |
|
|
Ok, ich habe es bis jetzt immer falsch gemacht und erst heute bemerkt...
Ein Bug ist das dann natürlich nicht, aber ich finde es schon sehr seltsam. Ich denke ich werde da in Zukunft immer mit "to" arbeiten. Das ist viel eindeutiger. |
|
| Nach oben |
|
|
Keltin
Anmeldungsdatum: 23.08.2012
Beiträge: 10
|
| Verfasst am: 23.08.2012, 14:08 Titel: |
|
|
Hallo,
ich glaub ich hab da einen Bug entdeckt.
Ich habe mit den neuen Compiler fbc 0.24.0 für Windows immer einen Absturz des Programmes wenn ich mit TSNEv3 arbeite sobalt das Programm beendet wird.
Dabei reicht schon ein simpler Code wie dieser:
| Code: |
#Include once "TSNE_V3.bi"
Print "Hallo Welt"
sleep
|
Wenn der gleiche Code mit fbc 0.23.0 für Windows compiliert wird gibt es keine Fehler.
Unter Win XP hängt sich das Programm nach drücken einer Taste auf und läst sich nur mit TaskManager beenden.
Bei Win7 x64 kommt die Meldung "Test.exe funktioniert nicht mehr" und man kann das Programm schließen oder online nach einer Lösung suchen lassen. |
|
| Nach oben |
|
|
Eternal_pain
Anmeldungsdatum: 08.08.2006
Beiträge: 1783
Wohnort: BW/KA
|
| Verfasst am: 23.08.2012, 14:21 Titel: |
|
|
Hab selbes Problem schon einmal in einem anderen Thread 'angesprochen' allerdings nicht weiter verfolgt da ich glaubte es läge an meinem System oder wär bei mir ein 'Einzelfall'
Dürfte allerdings nicht als bug im FBC zu tun haben (obwohl man es nicht ausschliessen kann) und sollte im entsprechenden Thread 'TSNE_V2 / V3 - Netzwerk-Modul' diskutiert werden damit man evtl rausfindet woran es liegt...
_________________
 |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 23.08.2012, 14:41 Titel: |
|
|
Im Vergleich zu 0.23 hat sich im ASM-Code etwas geändert, das zu dem Fehler führt. Das ist schon länger bekannt und eigentlich auch ansatzweise behoben, soweit ich mich erinnere. Die TSNE-Version im Portal scheint aber noch nicht geupdatet worden zu sein. Versuchs mal hiermit: http://ops.ath.cx/code?id=249
Übrigens: dieser Thread behandelt Fehler in der FreeBASIC Referenz im FreeBASIC-Portal und keine Compiler- oder sonstige Bugs. Dafür einfach einen neuen Thread starten. |
|
| Nach oben |
|
|
Keltin
Anmeldungsdatum: 23.08.2012
Beiträge: 10
|
| Verfasst am: 23.08.2012, 14:48 Titel: |
|
|
Danke für den Hinweis hab es im im entsprechenden Thread auch nochmal eingestellt.
Edit:
Der Link mit der neuen TSNE Version von MOD hat den Fehler Beseitigt.
Danke |
|
| Nach oben |
|
|
Toa-Nuva
Anmeldungsdatum: 14.04.2006
Beiträge: 204
Wohnort: München
|
| Verfasst am: 16.07.2014, 11:47 Titel: |
|
|
Ist mir gerade beim Beantworten eines anderen Posts aufgefallen: In der Referenz zu SCREENRES scheint sich ein kleiner Fehler eingeschlichen zu haben:
http://www.freebasic-portal.de/befehlsreferenz/screenres-372.html
Laut der Tabelle oben ist &h40 = GFX_ALPHA_PRIMITIVES. Weiter unten, bei den Unterschieden zu früheren FB-Versionen, steht allerdings: | Zitat: | | Folgende Flags existieren erst seit FreeBASIC v0.17: GFX_NO_FRAME (&h08), GFX_ALPHA_PRIMITIVES (&h80) und GFX_MULTISAMPLE (&h40000) |
Einmal &h40, einmal &h80... 
_________________
704 Signature not found |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4531
Wohnort: ~/
|
| Verfasst am: 16.07.2014, 13:09 Titel: |
|
|
Hmm, ja, und im Changelog steht bei fbc 0.17:
| Zitat: | | all gfx primitives can now respect the alpha channel; just init the screen with the new GFX_ALPHA_PRIMITIVES flag (&h20) |
Da müsste man nochmal 0.17 auspacken, um das zu prüfen. Es kann vorkommen, dass sich die Flags zwischen den Versionsnummern ändern (weshalb auch die Verwendung der Schlüsselwörter sehr empfehlenswert ist), und soweit ich mich erinnere haben wir genau deshalb die alten Zuordnungen dazugeschrieben. Allerdings kann ich auch im alten SCREEN-Artikel keine Hinweise entdecken, dass sich das Flag von 0.17 auf 0.18 geändert hat ...
Wahrscheinlich ist auch für fbc 0.17 GFX_ALPHA_PRIMITIVES = &h40 richtig, wäre aber gut, wenn das jemand nachprüfen könnte.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 557
Wohnort: Jüterbog
|
| Verfasst am: 04.11.2015, 21:05 Titel: |
|
|
Hmmm... soeben gesaugter aktueller Compiler:
| Code: | dim as integer i
for i=1 to 3
print i
next i
sleep |
| Zitat: | Build-Fehler:
C:\Users\Frank\Programmierung\Basic\Mühle\V_09\OpenForNext.bas(1) error 41: Variable not declared, d |
eine vorangestellte Kommentarzeile unterdrückt zwar den Fehler, jedoch macht das Programm nicht das was es soll.
V1.03 arbeitet mit o.g. Beispiel wie erwartet
Mutton |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 04.11.2015, 22:09 Titel: |
|
|
Dieser Thread ist für Bug-Reports zur Referenz, nicht zum Compiler. Hier wird niemals ein Entwickler deinen Report zu Gesicht bekommen.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 557
Wohnort: Jüterbog
|
| Verfasst am: 04.11.2015, 22:14 Titel: |
|
|
Das hab ich mir schon gedacht nachdem ich mir das Topic nochmal...
Macht nichts, es gibt Schlimmeres |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 05.11.2015, 20:25 Titel: |
|
|
Unter Windows kann ich weder mit der 32bit noch mit der 64bit Version des 1.04er fbc einen Fehler für das Codeschnipsel feststellen. Mehr Infos wären gut.
Edit: Konnte es reproduzieren, wenn ich die Datei als UCS-2 LE anlege und den Code dann da einfüge. |
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
