Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

FB-Referenz - Bug-Report
Gehe zu Seite Zurück  1, 2, 3, 4, 5  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Muttonhead



Anmeldungsdatum: 26.08.2008
Beiträge: 502
Wohnort: Jüterbog

BeitragVerfasst am: 27.01.2012, 22:45    Titel: Antworten mit Zitat

.. es wird ein wenig OT lächeln
Wollte lediglich darauf hinweisen, das eine in der Referenz beschriebene Eigenschaft von GET so (mit Strings) nicht nutzbar ist.

Mutton
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9695
Wohnort: Neben der Festplatte

BeitragVerfasst am: 28.01.2012, 13:37    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4131
Wohnort: ~/

BeitragVerfasst am: 28.01.2012, 14:39    Titel: Antworten mit Zitat

@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.
_________________
Meine Großeltern waren als junge Menschen sehr modern - sie hatten schon damals in der Badewanne Email.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Muttonhead



Anmeldungsdatum: 26.08.2008
Beiträge: 502
Wohnort: Jüterbog

BeitragVerfasst am: 28.01.2012, 16:23    Titel: Antworten mit Zitat

@nemored: um mehr gehts mir ja auch nicht, auch wenn ich es nicht explizit betont habe... lächeln

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 happy
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
volta



Anmeldungsdatum: 04.05.2005
Beiträge: 1845
Wohnort: D59192

BeitragVerfasst am: 28.01.2012, 17:20    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Muttonhead



Anmeldungsdatum: 26.08.2008
Beiträge: 502
Wohnort: Jüterbog

BeitragVerfasst am: 28.01.2012, 17:35    Titel: Antworten mit Zitat

Jahhhh Volta lächeln großes Kino
Zitat:
Code:
Cvi("RIFF")

Fühlst du dich nach sowas eigentlich besser? grinsen
Gefällt mir wirklich gut!!!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
volta



Anmeldungsdatum: 04.05.2005
Beiträge: 1845
Wohnort: D59192

BeitragVerfasst am: 28.01.2012, 19:19    Titel: Antworten mit Zitat

cool
solltest du diese einfache Schreibweise mal leid sein
Code:
riffhead.chunkID = *Cast(Integer Ptr, StrPtr("RIFF"))
geht auch happy
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Lou Ziffer



Anmeldungsdatum: 12.01.2012
Beiträge: 7

BeitragVerfasst am: 14.02.2012, 21:56    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 989

BeitragVerfasst am: 14.02.2012, 22:07    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Lou Ziffer



Anmeldungsdatum: 12.01.2012
Beiträge: 7

BeitragVerfasst am: 14.02.2012, 22:28    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Keltin



Anmeldungsdatum: 23.08.2012
Beiträge: 10

BeitragVerfasst am: 23.08.2012, 15:08    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Eternal_pain



Anmeldungsdatum: 08.08.2006
Beiträge: 1783
Wohnort: BW/KA

BeitragVerfasst am: 23.08.2012, 15:21    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen MSN Messenger
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 989

BeitragVerfasst am: 23.08.2012, 15:41    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Keltin



Anmeldungsdatum: 23.08.2012
Beiträge: 10

BeitragVerfasst am: 23.08.2012, 15:48    Titel: Antworten mit Zitat

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 grinsen
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Toa-Nuva



Anmeldungsdatum: 14.04.2006
Beiträge: 201
Wohnort: München

BeitragVerfasst am: 16.07.2014, 12:47    Titel: Antworten mit Zitat

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... zwinkern
_________________
704 Signature not found
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4131
Wohnort: ~/

BeitragVerfasst am: 16.07.2014, 14:09    Titel: Antworten mit Zitat

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. happy
_________________
Meine Großeltern waren als junge Menschen sehr modern - sie hatten schon damals in der Badewanne Email.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Muttonhead



Anmeldungsdatum: 26.08.2008
Beiträge: 502
Wohnort: Jüterbog

BeitragVerfasst am: 04.11.2015, 22:05    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9695
Wohnort: Neben der Festplatte

BeitragVerfasst am: 04.11.2015, 23:09    Titel: Antworten mit Zitat

Dieser Thread ist für Bug-Reports zur Referenz, nicht zum Compiler. Hier wird niemals ein Entwickler deinen Report zu Gesicht bekommen. zwinkern
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Muttonhead



Anmeldungsdatum: 26.08.2008
Beiträge: 502
Wohnort: Jüterbog

BeitragVerfasst am: 04.11.2015, 23:14    Titel: Antworten mit Zitat

Das hab ich mir schon gedacht nachdem ich mir das Topic nochmal...
Macht nichts, es gibt Schlimmeres happy
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 989

BeitragVerfasst am: 05.11.2015, 21:25    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite Zurück  1, 2, 3, 4, 5  Weiter
Seite 4 von 5

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz