From lordheavym at ...176... Mon Oct 1 14:04:27 2012 From: lordheavym at ...176... (Laurent Carlier) Date: Mon, 01 Oct 2012 14:04:27 +0200 Subject: [Gambas-devel] image-effect key value Message-ID: <42160157.HsTA4tYa2W@...676...> gb.image.effect.component file [Component] Key=gb.image.component Name=Image processing component Author=Beno?t Minisini Requires=gb.image key should be gb.image.effect ? I also currently update the wiki about package (3.0) dependencies, please review. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From gambas at ...1... Mon Oct 1 14:07:13 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Mon, 01 Oct 2012 14:07:13 +0200 Subject: [Gambas-devel] image-effect key value In-Reply-To: <42160157.HsTA4tYa2W@...676...> References: <42160157.HsTA4tYa2W@...676...> Message-ID: <50698771.6040009@...1...> Le 01/10/2012 14:04, Laurent Carlier a ?crit : > gb.image.effect.component file > > [Component] > Key=gb.image.component > Name=Image processing component > Author=Beno?t Minisini > Requires=gb.image > > key should be gb.image.effect ? The Key and Name are actually not used anymore. :-) They are stored inside the IDE now. > > I also currently update the wiki about package (3.0) dependencies, please > review. Where? -- Beno?t Minisini From lordheavym at ...176... Mon Oct 1 14:08:01 2012 From: lordheavym at ...176... (Laurent Carlier) Date: Mon, 01 Oct 2012 14:08:01 +0200 Subject: [Gambas-devel] image-effect key value In-Reply-To: <42160157.HsTA4tYa2W@...676...> References: <42160157.HsTA4tYa2W@...676...> Message-ID: <4853852.9IYu0nX5sk@...676...> Le lundi 1 octobre 2012 14:04:27 vous avez ?crit : > gb.image.effect.component file > > [Component] > Key=gb.image.component > Name=Image processing component > Author=Beno?t Minisini > Requires=gb.image > > key should be gb.image.effect ? > > I also currently update the wiki about package (3.0) dependencies, please > review. Seem similar with gb.complex.component file [Component] Key=gb.component Author=Beno?t Minisini Implements=Complex also gb.eval.component got duplicated entries ?? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From lordheavym at ...176... Mon Oct 1 14:17:54 2012 From: lordheavym at ...176... (Laurent Carlier) Date: Mon, 01 Oct 2012 14:17:54 +0200 Subject: [Gambas-devel] image-effect key value In-Reply-To: <50698771.6040009@...1...> References: <42160157.HsTA4tYa2W@...676...> <50698771.6040009@...1...> Message-ID: <6712908.mvruJHYhRB@...676...> Le lundi 1 octobre 2012 14:07:13 Beno?t Minisini a ?crit : > Le 01/10/2012 14:04, Laurent Carlier a ?crit : > > gb.image.effect.component file > > > > [Component] > > Key=gb.image.component > > Name=Image processing component > > Author=Beno?t Minisini > > Requires=gb.image > > > > key should be gb.image.effect ? > > The Key and Name are actually not used anymore. :-) They are stored > inside the IDE now. > > > I also currently update the wiki about package (3.0) dependencies, please > > review. > > Where? gb.complex component should also be part of gambas3-runtime package (as it can be superseded by gb.gsl component) http://gambasdoc.org/help/howto/package?v3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From gambas at ...1... Mon Oct 1 14:25:18 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Mon, 01 Oct 2012 14:25:18 +0200 Subject: [Gambas-devel] image-effect key value In-Reply-To: <6712908.mvruJHYhRB@...676...> References: <42160157.HsTA4tYa2W@...676...> <50698771.6040009@...1...> <6712908.mvruJHYhRB@...676...> Message-ID: <50698BAE.8070405@...1...> Le 01/10/2012 14:17, Laurent Carlier a ?crit : > > gb.complex component should also be part of gambas3-runtime package (as it can > be superseded by gb.gsl component) Why? You can run gambas with explicit complex number support from gb.gsl, with explicit complex number support from gb.complex, or with the implicit complex number support from gb.complex, or without any complex number support if gb.complex is not installed in the system. -- Beno?t Minisini From lordheavym at ...176... Mon Oct 1 14:41:35 2012 From: lordheavym at ...176... (Laurent Carlier) Date: Mon, 01 Oct 2012 14:41:35 +0200 Subject: [Gambas-devel] image-effect key value In-Reply-To: <50698BAE.8070405@...1...> References: <42160157.HsTA4tYa2W@...676...> <6712908.mvruJHYhRB@...676...> <50698BAE.8070405@...1...> Message-ID: <2646283.yNpqKEmXOH@...676...> Le lundi 1 octobre 2012 14:25:18 Beno?t Minisini a ?crit : > Le 01/10/2012 14:17, Laurent Carlier a ?crit : > > gb.complex component should also be part of gambas3-runtime package (as it > > can be superseded by gb.gsl component) > > Why? You can run gambas with explicit complex number support from > gb.gsl, with explicit complex number support from gb.complex, or with > the implicit complex number support from gb.complex, or without any > complex number support if gb.complex is not installed in the system. So an Application can say "Hey, i want complex number support!", So gambas will make these steps ?: check for gb.gsl -> yes -> ok \-> no -> check for gb.complex -> yes -> ok \-> no -> error (or fallback/disabling) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From gambas at ...1... Mon Oct 1 14:48:15 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Mon, 01 Oct 2012 14:48:15 +0200 Subject: [Gambas-devel] image-effect key value In-Reply-To: <2646283.yNpqKEmXOH@...676...> References: <42160157.HsTA4tYa2W@...676...> <6712908.mvruJHYhRB@...676...> <50698BAE.8070405@...1...> <2646283.yNpqKEmXOH@...676...> Message-ID: <5069910F.3080006@...1...> Le 01/10/2012 14:41, Laurent Carlier a ?crit : > Le lundi 1 octobre 2012 14:25:18 Beno?t Minisini a ?crit : >> Le 01/10/2012 14:17, Laurent Carlier a ?crit : >>> gb.complex component should also be part of gambas3-runtime package (as it >>> can be superseded by gb.gsl component) >> >> Why? You can run gambas with explicit complex number support from >> gb.gsl, with explicit complex number support from gb.complex, or with >> the implicit complex number support from gb.complex, or without any >> complex number support if gb.complex is not installed in the system. > > So an Application can say "Hey, i want complex number support!", So gambas > will make these steps ?: > > check for gb.gsl -> yes -> ok > \-> no -> check for gb.complex -> yes -> ok > \-> no -> error (or fallback/disabling) > No, it just checks for gb.complex (like it does for gb.eval). gb.gsl must be used explicitely. And if gb.gsl is used, of course gb.complex is never checked. See `EXEC_push_complex()` in `gbx_exec.c` source file. -- Beno?t Minisini From ron at ...572... Tue Oct 2 20:20:38 2012 From: ron at ...572... (Ron) Date: Tue, 2 Oct 2012 20:20:38 +0200 Subject: [Gambas-devel] Project convert bug Message-ID: This line isn't convert by the project converter: Dim aMBusId, aMBusType, aMBusReading, aMBusUnit, aMBusValve, aMBusTime As String[4] Must be: Dim aMBusId, aMBusType, aMBusReading, aMBusUnit, aMBusValve, aMBusTime As New String[4] URL: https://gambas.svn.sourceforge.net/svnroot/gambas/gambas/trunk Revision: 5221 Regards, Ron_2nd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Wed Oct 3 20:45:15 2012 From: tobias at ...692... (Tobias Boege) Date: Wed, 3 Oct 2012 20:45:15 +0200 Subject: [Gambas-devel] New(er) enumeration API Message-ID: <20121003184515.GA528@...693...> Hi, today while debugging the new List code for gb.data I encountered problems with the new enumeration API. There are _few_ places to learn from (I took CResult.c) but apparently something doesn't quite work out with it: I want to run through all references I manage for a chunk in a List (a 'chunk' contains some Variants). These are the 'Current' pointer and all the enumerations currently active. The ultimate goal is to update members of these reference structures just because the elements they point to in the chunk changed their location. The convenience macro looks like this: #define for_all_persistent_vals(list, vp, es, ebuf) \ for (ebuf = GB.BeginEnum(list), vp = &list->current, es = NULL; \ vp ? 1 : (GB.EndEnum(ebuf), 0); \ !GB.NextEnum() ? (es = (struct enum_state*) GB.GetEnum(),\ vp = &es->next) : (vp = NULL)) (admittely not a very appealing piece of code) where 'list' is the Gambas List object, 'vp' is a pointer to the structure I want to update, 'es' is my struct enum_state and 'ebuf' is whatever I get back from GB.BeginEnum() and have to pass to GB.EndEnum(). The thing now is that, even if no enumeration runs in the Gambas code, I get some 'es' which contains information that could actually have been valid (in fact, it refers to the last enumerated object in the last enumeration). For some reason, the important part (the pointer to the chunk which sits at offset 0 from the 'es' pointer) is set to NULL and thus, my library segfaults on NULL pointer dereference. Benoit, can you please enlighten me if I am doing something wrong with these functions? Regards, Tobi From tobias at ...692... Wed Oct 3 20:56:19 2012 From: tobias at ...692... (Tobias Boege) Date: Wed, 3 Oct 2012 20:56:19 +0200 Subject: [Gambas-devel] New(er) enumeration API In-Reply-To: <20121003184515.GA528@...693...> References: <20121003184515.GA528@...693...> Message-ID: <20121003185619.GB528@...693...> On Wed, 03 Oct 2012, Tobias Boege wrote: > Hi, > > today while debugging the new List code for gb.data I encountered problems > with the new enumeration API. There are _few_ places to learn from (I took > CResult.c) but apparently something doesn't quite work out with it: > > I want to run through all references I manage for a chunk in a List (a > 'chunk' contains some Variants). These are the 'Current' pointer and all the > enumerations currently active. The ultimate goal is to update members of > these reference structures just because the elements they point to in the > chunk changed their location. The convenience macro looks like this: > > #define for_all_persistent_vals(list, vp, es, ebuf) \ > for (ebuf = GB.BeginEnum(list), vp = &list->current, es = NULL; \ > vp ? 1 : (GB.EndEnum(ebuf), 0); \ > !GB.NextEnum() ? (es = (struct enum_state*) GB.GetEnum(),\ > vp = &es->next) : (vp = NULL)) > > (admittely not a very appealing piece of code) > > where 'list' is the Gambas List object, 'vp' is a pointer to the structure > I want to update, 'es' is my struct enum_state and 'ebuf' is whatever I get > back from GB.BeginEnum() and have to pass to GB.EndEnum(). > > The thing now is that, even if no enumeration runs in the Gambas code, I get > some 'es' which contains information that could actually have been valid (in > fact, it refers to the last enumerated object in the last enumeration). > For some reason, the important part (the pointer to the chunk which sits at > offset 0 from the 'es' pointer) is set to NULL and thus, my library > segfaults on NULL pointer dereference. > Actually, I set it myself to NULL which indicates the end of enumeration to the List_next routine. But why does that 'es' appear again without being in enumeration? I have a really bad feeling now since I only get the 'es' filled if I put in some basically unrelated Gambas code before the List.Take() from which the above problem originates... I just want to know: Is it possible under normal circumstances to get an old non-running enumerator from that GB.*Enum() interface? > Benoit, can you please enlighten me if I am doing something wrong with these > functions? From gambas at ...1... Wed Oct 3 21:24:41 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Wed, 03 Oct 2012 21:24:41 +0200 Subject: [Gambas-devel] New(er) enumeration API In-Reply-To: <20121003185619.GB528@...693...> References: <20121003184515.GA528@...693...> <20121003185619.GB528@...693...> Message-ID: <506C90F9.4000805@...1...> Le 03/10/2012 20:56, Tobias Boege a ?crit : > On Wed, 03 Oct 2012, Tobias Boege wrote: >> Hi, >> >> today while debugging the new List code for gb.data I encountered problems >> with the new enumeration API. There are _few_ places to learn from (I took >> CResult.c) but apparently something doesn't quite work out with it: >> >> I want to run through all references I manage for a chunk in a List (a >> 'chunk' contains some Variants). These are the 'Current' pointer and all the >> enumerations currently active. The ultimate goal is to update members of >> these reference structures just because the elements they point to in the >> chunk changed their location. The convenience macro looks like this: >> >> #define for_all_persistent_vals(list, vp, es, ebuf) \ >> for (ebuf = GB.BeginEnum(list), vp = &list->current, es = NULL; \ >> vp ? 1 : (GB.EndEnum(ebuf), 0); \ >> !GB.NextEnum() ? (es = (struct enum_state*) GB.GetEnum(),\ >> vp = &es->next) : (vp = NULL)) >> >> (admittely not a very appealing piece of code) >> >> where 'list' is the Gambas List object, 'vp' is a pointer to the structure >> I want to update, 'es' is my struct enum_state and 'ebuf' is whatever I get >> back from GB.BeginEnum() and have to pass to GB.EndEnum(). >> >> The thing now is that, even if no enumeration runs in the Gambas code, I get >> some 'es' which contains information that could actually have been valid (in >> fact, it refers to the last enumerated object in the last enumeration). >> For some reason, the important part (the pointer to the chunk which sits at >> offset 0 from the 'es' pointer) is set to NULL and thus, my library >> segfaults on NULL pointer dereference. >> > > Actually, I set it myself to NULL which indicates the end of enumeration to > the List_next routine. But why does that 'es' appear again without being in > enumeration? > > I have a really bad feeling now since I only get the 'es' filled if I put in > some basically unrelated Gambas code before the List.Take() from which the > above problem originates... > > I just want to know: Is it possible under normal circumstances to get an old > non-running enumerator from that GB.*Enum() interface? > >> Benoit, can you please enlighten me if I am doing something wrong with these >> functions? > I can't know. See me the full code because you can't do what you want between GB.BeginEnum() ... GB.EndEnum() (i.e. you can't do something that may call another enumeration-related function). Moreover, I'm not sure that your spaghetti macro is right. Can you rewrite it as clear as possible (i.e. without using the ',' operator)? -- Beno?t Minisini From gambas at ...1... Wed Oct 3 21:40:17 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Wed, 03 Oct 2012 21:40:17 +0200 Subject: [Gambas-devel] Project convert bug In-Reply-To: References: Message-ID: <506C94A1.6050906@...1...> Le 02/10/2012 20:20, Ron a ?crit : > This line isn't convert by the project converter: > > Dim aMBusId, aMBusType, aMBusReading, aMBusUnit, aMBusValve, aMBusTime As > String[4] > > Must be: > > Dim aMBusId, aMBusType, aMBusReading, aMBusUnit, aMBusValve, aMBusTime As > New String[4] > > URL: https://gambas.svn.sourceforge.net/svnroot/gambas/gambas/trunk > Revision: 5221 > > > Regards, > Ron_2nd. > It should be fixed in revision #5224. Regards, -- Beno?t Minisini From tobias at ...692... Wed Oct 3 22:15:55 2012 From: tobias at ...692... (Tobias Boege) Date: Wed, 3 Oct 2012 22:15:55 +0200 Subject: [Gambas-devel] New(er) enumeration API In-Reply-To: <506C90F9.4000805@...1...> References: <20121003184515.GA528@...693...> <20121003185619.GB528@...693...> <506C90F9.4000805@...1...> Message-ID: <20121003201555.GC528@...693...> On Wed, 03 Oct 2012, Beno?t Minisini wrote: > Le 03/10/2012 20:56, Tobias Boege a ?crit : > > On Wed, 03 Oct 2012, Tobias Boege wrote: > >> Hi, > >> > >> today while debugging the new List code for gb.data I encountered problems > >> with the new enumeration API. There are _few_ places to learn from (I took > >> CResult.c) but apparently something doesn't quite work out with it: > >> > >> I want to run through all references I manage for a chunk in a List (a > >> 'chunk' contains some Variants). These are the 'Current' pointer and all the > >> enumerations currently active. The ultimate goal is to update members of > >> these reference structures just because the elements they point to in the > >> chunk changed their location. The convenience macro looks like this: > >> > >> #define for_all_persistent_vals(list, vp, es, ebuf) \ > >> for (ebuf = GB.BeginEnum(list), vp = &list->current, es = NULL; \ > >> vp ? 1 : (GB.EndEnum(ebuf), 0); \ > >> !GB.NextEnum() ? (es = (struct enum_state*) GB.GetEnum(),\ > >> vp = &es->next) : (vp = NULL)) > >> > >> (admittely not a very appealing piece of code) > >> > >> where 'list' is the Gambas List object, 'vp' is a pointer to the structure > >> I want to update, 'es' is my struct enum_state and 'ebuf' is whatever I get > >> back from GB.BeginEnum() and have to pass to GB.EndEnum(). > >> > >> The thing now is that, even if no enumeration runs in the Gambas code, I get > >> some 'es' which contains information that could actually have been valid (in > >> fact, it refers to the last enumerated object in the last enumeration). > >> For some reason, the important part (the pointer to the chunk which sits at > >> offset 0 from the 'es' pointer) is set to NULL and thus, my library > >> segfaults on NULL pointer dereference. > >> > > > > Actually, I set it myself to NULL which indicates the end of enumeration to > > the List_next routine. But why does that 'es' appear again without being in > > enumeration? > > > > I have a really bad feeling now since I only get the 'es' filled if I put in > > some basically unrelated Gambas code before the List.Take() from which the > > above problem originates... > > > > I just want to know: Is it possible under normal circumstances to get an old > > non-running enumerator from that GB.*Enum() interface? > > > >> Benoit, can you please enlighten me if I am doing something wrong with these > >> functions? > > > > I can't know. See me the full code because you can't do what you want > between GB.BeginEnum() ... GB.EndEnum() (i.e. you can't do something > that may call another enumeration-related function). > > Moreover, I'm not sure that your spaghetti macro is right. Can you > rewrite it as clear as possible (i.e. without using the ',' operator)? Here it goes: ebuf = GB.BeginEnum(list); vp = &list->current; /* Begin with Current */ es = NULL; /* Just signal that vp is not an enumerator */ while (vp) { if (!GB.NextEnum()) break; /* In the macro it does this by setting vp = NULL */ es = GB.GetEnum(); vp = &es->next; /* Here goes the loop body */ } GB.EndEnum(list); I'm modifying only the 'vp' structures in there. Regards, Tobi From tobias at ...692... Wed Oct 3 22:17:36 2012 From: tobias at ...692... (Tobias Boege) Date: Wed, 3 Oct 2012 22:17:36 +0200 Subject: [Gambas-devel] New(er) enumeration API In-Reply-To: <20121003201555.GC528@...693...> References: <20121003184515.GA528@...693...> <20121003185619.GB528@...693...> <506C90F9.4000805@...1...> <20121003201555.GC528@...693...> Message-ID: <20121003201736.GD528@...693...> On Wed, 03 Oct 2012, Tobias Boege wrote: > On Wed, 03 Oct 2012, Beno?t Minisini wrote: > > Le 03/10/2012 20:56, Tobias Boege a ?crit : > > > On Wed, 03 Oct 2012, Tobias Boege wrote: > > >> Hi, > > >> > > >> today while debugging the new List code for gb.data I encountered problems > > >> with the new enumeration API. There are _few_ places to learn from (I took > > >> CResult.c) but apparently something doesn't quite work out with it: > > >> > > >> I want to run through all references I manage for a chunk in a List (a > > >> 'chunk' contains some Variants). These are the 'Current' pointer and all the > > >> enumerations currently active. The ultimate goal is to update members of > > >> these reference structures just because the elements they point to in the > > >> chunk changed their location. The convenience macro looks like this: > > >> > > >> #define for_all_persistent_vals(list, vp, es, ebuf) \ > > >> for (ebuf = GB.BeginEnum(list), vp = &list->current, es = NULL; \ > > >> vp ? 1 : (GB.EndEnum(ebuf), 0); \ > > >> !GB.NextEnum() ? (es = (struct enum_state*) GB.GetEnum(),\ > > >> vp = &es->next) : (vp = NULL)) > > >> > > >> (admittely not a very appealing piece of code) > > >> > > >> where 'list' is the Gambas List object, 'vp' is a pointer to the structure > > >> I want to update, 'es' is my struct enum_state and 'ebuf' is whatever I get > > >> back from GB.BeginEnum() and have to pass to GB.EndEnum(). > > >> > > >> The thing now is that, even if no enumeration runs in the Gambas code, I get > > >> some 'es' which contains information that could actually have been valid (in > > >> fact, it refers to the last enumerated object in the last enumeration). > > >> For some reason, the important part (the pointer to the chunk which sits at > > >> offset 0 from the 'es' pointer) is set to NULL and thus, my library > > >> segfaults on NULL pointer dereference. > > >> > > > > > > Actually, I set it myself to NULL which indicates the end of enumeration to > > > the List_next routine. But why does that 'es' appear again without being in > > > enumeration? > > > > > > I have a really bad feeling now since I only get the 'es' filled if I put in > > > some basically unrelated Gambas code before the List.Take() from which the > > > above problem originates... > > > > > > I just want to know: Is it possible under normal circumstances to get an old > > > non-running enumerator from that GB.*Enum() interface? > > > > > >> Benoit, can you please enlighten me if I am doing something wrong with these > > >> functions? > > > > > > > I can't know. See me the full code because you can't do what you want > > between GB.BeginEnum() ... GB.EndEnum() (i.e. you can't do something > > that may call another enumeration-related function). > > > > Moreover, I'm not sure that your spaghetti macro is right. Can you > > rewrite it as clear as possible (i.e. without using the ',' operator)? > > Here it goes: > > ebuf = GB.BeginEnum(list); > vp = &list->current; /* Begin with Current */ > es = NULL; /* Just signal that vp is not an enumerator */ > while (vp) { > if (!GB.NextEnum()) > break; /* In the macro it does this by setting vp = NULL */ > es = GB.GetEnum(); > vp = &es->next; > /* Here goes the loop body */ > } > GB.EndEnum(list); It has, of course, to be GB.EndEnum(ebuf); From tobias at ...692... Wed Oct 3 22:22:54 2012 From: tobias at ...692... (Tobias Boege) Date: Wed, 3 Oct 2012 22:22:54 +0200 Subject: [Gambas-devel] New(er) enumeration API In-Reply-To: <20121003201736.GD528@...693...> References: <20121003184515.GA528@...693...> <20121003185619.GB528@...693...> <506C90F9.4000805@...1...> <20121003201555.GC528@...693...> <20121003201736.GD528@...693...> Message-ID: <20121003202254.GE528@...693...> On Wed, 03 Oct 2012, Tobias Boege wrote: > On Wed, 03 Oct 2012, Tobias Boege wrote: > > On Wed, 03 Oct 2012, Beno?t Minisini wrote: > > > Le 03/10/2012 20:56, Tobias Boege a ?crit : > > > > On Wed, 03 Oct 2012, Tobias Boege wrote: > > > >> Hi, > > > >> > > > >> today while debugging the new List code for gb.data I encountered problems > > > >> with the new enumeration API. There are _few_ places to learn from (I took > > > >> CResult.c) but apparently something doesn't quite work out with it: > > > >> > > > >> I want to run through all references I manage for a chunk in a List (a > > > >> 'chunk' contains some Variants). These are the 'Current' pointer and all the > > > >> enumerations currently active. The ultimate goal is to update members of > > > >> these reference structures just because the elements they point to in the > > > >> chunk changed their location. The convenience macro looks like this: > > > >> > > > >> #define for_all_persistent_vals(list, vp, es, ebuf) \ > > > >> for (ebuf = GB.BeginEnum(list), vp = &list->current, es = NULL; \ > > > >> vp ? 1 : (GB.EndEnum(ebuf), 0); \ > > > >> !GB.NextEnum() ? (es = (struct enum_state*) GB.GetEnum(),\ > > > >> vp = &es->next) : (vp = NULL)) > > > >> > > > >> (admittely not a very appealing piece of code) > > > >> > > > >> where 'list' is the Gambas List object, 'vp' is a pointer to the structure > > > >> I want to update, 'es' is my struct enum_state and 'ebuf' is whatever I get > > > >> back from GB.BeginEnum() and have to pass to GB.EndEnum(). > > > >> > > > >> The thing now is that, even if no enumeration runs in the Gambas code, I get > > > >> some 'es' which contains information that could actually have been valid (in > > > >> fact, it refers to the last enumerated object in the last enumeration). > > > >> For some reason, the important part (the pointer to the chunk which sits at > > > >> offset 0 from the 'es' pointer) is set to NULL and thus, my library > > > >> segfaults on NULL pointer dereference. > > > >> > > > > > > > > Actually, I set it myself to NULL which indicates the end of enumeration to > > > > the List_next routine. But why does that 'es' appear again without being in > > > > enumeration? > > > > > > > > I have a really bad feeling now since I only get the 'es' filled if I put in > > > > some basically unrelated Gambas code before the List.Take() from which the > > > > above problem originates... > > > > > > > > I just want to know: Is it possible under normal circumstances to get an old > > > > non-running enumerator from that GB.*Enum() interface? > > > > > > > >> Benoit, can you please enlighten me if I am doing something wrong with these > > > >> functions? > > > > > > > > > > I can't know. See me the full code because you can't do what you want > > > between GB.BeginEnum() ... GB.EndEnum() (i.e. you can't do something > > > that may call another enumeration-related function). > > > > > > Moreover, I'm not sure that your spaghetti macro is right. Can you > > > rewrite it as clear as possible (i.e. without using the ',' operator)? Arrg! And the loop body must be before that unrolled while-body, so that: ebuf = GB.BeginEnum(list); vp = &list->current; /* Begin with Current */ es = NULL; /* Just signal that vp is not an enumerator */ while (vp) { /* Here goes the loop body, modifying vp */ /* Get all enumerators next */ if (!GB.NextEnum()) break; /* In the macro done via vp = NULL */ es = GB.GetEnum(); vp = &es->next; } GB.EndEnum(ebuf); From gambas at ...1... Mon Oct 8 15:52:57 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Mon, 08 Oct 2012 15:52:57 +0200 Subject: [Gambas-devel] New(er) enumeration API In-Reply-To: <20121003202254.GE528@...693...> References: <20121003184515.GA528@...693...> <20121003185619.GB528@...693...> <506C90F9.4000805@...1...> <20121003201555.GC528@...693...> <20121003201736.GD528@...693...> <20121003202254.GE528@...693...> Message-ID: <5072DAB9.3030107@...1...> Le 03/10/2012 22:22, Tobias Boege a ?crit : > On Wed, 03 Oct 2012, Tobias Boege wrote: >> On Wed, 03 Oct 2012, Tobias Boege wrote: >>> On Wed, 03 Oct 2012, Beno?t Minisini wrote: >>>> Le 03/10/2012 20:56, Tobias Boege a ?crit : >>>>> On Wed, 03 Oct 2012, Tobias Boege wrote: >>>>>> Hi, >>>>>> >>>>>> today while debugging the new List code for gb.data I encountered problems >>>>>> with the new enumeration API. There are _few_ places to learn from (I took >>>>>> CResult.c) but apparently something doesn't quite work out with it: >>>>>> >>>>>> I want to run through all references I manage for a chunk in a List (a >>>>>> 'chunk' contains some Variants). These are the 'Current' pointer and all the >>>>>> enumerations currently active. The ultimate goal is to update members of >>>>>> these reference structures just because the elements they point to in the >>>>>> chunk changed their location. The convenience macro looks like this: >>>>>> >>>>>> #define for_all_persistent_vals(list, vp, es, ebuf) \ >>>>>> for (ebuf = GB.BeginEnum(list), vp = &list->current, es = NULL; \ >>>>>> vp ? 1 : (GB.EndEnum(ebuf), 0); \ >>>>>> !GB.NextEnum() ? (es = (struct enum_state*) GB.GetEnum(),\ >>>>>> vp = &es->next) : (vp = NULL)) >>>>>> >>>>>> (admittely not a very appealing piece of code) >>>>>> >>>>>> where 'list' is the Gambas List object, 'vp' is a pointer to the structure >>>>>> I want to update, 'es' is my struct enum_state and 'ebuf' is whatever I get >>>>>> back from GB.BeginEnum() and have to pass to GB.EndEnum(). >>>>>> >>>>>> The thing now is that, even if no enumeration runs in the Gambas code, I get >>>>>> some 'es' which contains information that could actually have been valid (in >>>>>> fact, it refers to the last enumerated object in the last enumeration). >>>>>> For some reason, the important part (the pointer to the chunk which sits at >>>>>> offset 0 from the 'es' pointer) is set to NULL and thus, my library >>>>>> segfaults on NULL pointer dereference. >>>>>> >>>>> >>>>> Actually, I set it myself to NULL which indicates the end of enumeration to >>>>> the List_next routine. But why does that 'es' appear again without being in >>>>> enumeration? >>>>> >>>>> I have a really bad feeling now since I only get the 'es' filled if I put in >>>>> some basically unrelated Gambas code before the List.Take() from which the >>>>> above problem originates... >>>>> >>>>> I just want to know: Is it possible under normal circumstances to get an old >>>>> non-running enumerator from that GB.*Enum() interface? >>>>> >>>>>> Benoit, can you please enlighten me if I am doing something wrong with these >>>>>> functions? >>>>> >>>> >>>> I can't know. See me the full code because you can't do what you want >>>> between GB.BeginEnum() ... GB.EndEnum() (i.e. you can't do something >>>> that may call another enumeration-related function). >>>> >>>> Moreover, I'm not sure that your spaghetti macro is right. Can you >>>> rewrite it as clear as possible (i.e. without using the ',' operator)? > > Arrg! And the loop body must be before that unrolled while-body, so that: > > ebuf = GB.BeginEnum(list); > vp = &list->current; /* Begin with Current */ > es = NULL; /* Just signal that vp is not an enumerator */ > while (vp) { > /* Here goes the loop body, modifying vp */ > > /* Get all enumerators next */ > if (!GB.NextEnum()) > break; /* In the macro done via vp = NULL */ > es = GB.GetEnum(); > vp = &es->next; > } > GB.EndEnum(ebuf); > Can you commit your code and give me a project example of the bug? -- Beno?t Minisini From tobias at ...692... Mon Oct 8 16:32:13 2012 From: tobias at ...692... (Tobias Boege) Date: Mon, 8 Oct 2012 16:32:13 +0200 Subject: [Gambas-devel] New(er) enumeration API In-Reply-To: <5072DAB9.3030107@...1...> References: <20121003184515.GA528@...693...> <20121003185619.GB528@...693...> <506C90F9.4000805@...1...> <20121003201555.GC528@...693...> <20121003201736.GD528@...693...> <20121003202254.GE528@...693...> <5072DAB9.3030107@...1...> Message-ID: <20121008143213.GA1000@...693...> On Mon, 08 Oct 2012, Beno?t Minisini wrote: > Le 03/10/2012 22:22, Tobias Boege a ?crit : > > On Wed, 03 Oct 2012, Tobias Boege wrote: > >> On Wed, 03 Oct 2012, Tobias Boege wrote: > >>> On Wed, 03 Oct 2012, Beno?t Minisini wrote: > >>>> Le 03/10/2012 20:56, Tobias Boege a ?crit : > >>>>> On Wed, 03 Oct 2012, Tobias Boege wrote: > >>>>>> Hi, > >>>>>> > >>>>>> today while debugging the new List code for gb.data I encountered problems > >>>>>> with the new enumeration API. There are _few_ places to learn from (I took > >>>>>> CResult.c) but apparently something doesn't quite work out with it: > >>>>>> > >>>>>> I want to run through all references I manage for a chunk in a List (a > >>>>>> 'chunk' contains some Variants). These are the 'Current' pointer and all the > >>>>>> enumerations currently active. The ultimate goal is to update members of > >>>>>> these reference structures just because the elements they point to in the > >>>>>> chunk changed their location. The convenience macro looks like this: > >>>>>> > >>>>>> #define for_all_persistent_vals(list, vp, es, ebuf) \ > >>>>>> for (ebuf = GB.BeginEnum(list), vp = &list->current, es = NULL; \ > >>>>>> vp ? 1 : (GB.EndEnum(ebuf), 0); \ > >>>>>> !GB.NextEnum() ? (es = (struct enum_state*) GB.GetEnum(),\ > >>>>>> vp = &es->next) : (vp = NULL)) > >>>>>> > >>>>>> (admittely not a very appealing piece of code) > >>>>>> > >>>>>> where 'list' is the Gambas List object, 'vp' is a pointer to the structure > >>>>>> I want to update, 'es' is my struct enum_state and 'ebuf' is whatever I get > >>>>>> back from GB.BeginEnum() and have to pass to GB.EndEnum(). > >>>>>> > >>>>>> The thing now is that, even if no enumeration runs in the Gambas code, I get > >>>>>> some 'es' which contains information that could actually have been valid (in > >>>>>> fact, it refers to the last enumerated object in the last enumeration). > >>>>>> For some reason, the important part (the pointer to the chunk which sits at > >>>>>> offset 0 from the 'es' pointer) is set to NULL and thus, my library > >>>>>> segfaults on NULL pointer dereference. > >>>>>> > >>>>> > >>>>> Actually, I set it myself to NULL which indicates the end of enumeration to > >>>>> the List_next routine. But why does that 'es' appear again without being in > >>>>> enumeration? > >>>>> > >>>>> I have a really bad feeling now since I only get the 'es' filled if I put in > >>>>> some basically unrelated Gambas code before the List.Take() from which the > >>>>> above problem originates... > >>>>> > >>>>> I just want to know: Is it possible under normal circumstances to get an old > >>>>> non-running enumerator from that GB.*Enum() interface? > >>>>> > >>>>>> Benoit, can you please enlighten me if I am doing something wrong with these > >>>>>> functions? > >>>>> > >>>> > >>>> I can't know. See me the full code because you can't do what you want > >>>> between GB.BeginEnum() ... GB.EndEnum() (i.e. you can't do something > >>>> that may call another enumeration-related function). > >>>> > >>>> Moreover, I'm not sure that your spaghetti macro is right. Can you > >>>> rewrite it as clear as possible (i.e. without using the ',' operator)? > > > > Arrg! And the loop body must be before that unrolled while-body, so that: > > > > ebuf = GB.BeginEnum(list); > > vp = &list->current; /* Begin with Current */ > > es = NULL; /* Just signal that vp is not an enumerator */ > > while (vp) { > > /* Here goes the loop body, modifying vp */ > > > > /* Get all enumerators next */ > > if (!GB.NextEnum()) > > break; /* In the macro done via vp = NULL */ > > es = GB.GetEnum(); > > vp = &es->next; > > } > > GB.EndEnum(ebuf); > > > > Can you commit your code and give me a project example of the bug? > I will commit (with a worked-around code) when it works so that I can kill two birds with one stone then... From gambas at ...1... Mon Oct 8 16:39:40 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Mon, 08 Oct 2012 16:39:40 +0200 Subject: [Gambas-devel] New(er) enumeration API In-Reply-To: <20121008143213.GA1000@...693...> References: <20121003184515.GA528@...693...> <20121003185619.GB528@...693...> <506C90F9.4000805@...1...> <20121003201555.GC528@...693...> <20121003201736.GD528@...693...> <20121003202254.GE528@...693...> <5072DAB9.3030107@...1...> <20121008143213.GA1000@...693...> Message-ID: <5072E5AC.3060009@...1...> Le 08/10/2012 16:32, Tobias Boege a ?crit : >> >> Can you commit your code and give me a project example of the bug? >> > > I will commit (with a worked-around code) when it works so that I can kill > two birds with one stone then... > OK, but I can't fix the bug if you don't commit the bad code and give me an example! :-) -- Beno?t Minisini From sebikul at ...176... Sat Oct 27 06:30:14 2012 From: sebikul at ...176... (Sebastian Kulesz) Date: Sat, 27 Oct 2012 01:30:14 -0300 Subject: [Gambas-devel] gb.gui.base packaging Message-ID: Hi! The recent commit for the new gb.gui.base broke the daily builds ppa packages. My first guess is that it should be included with the gb.gui package, right? The thing is, gb.gui depends both on gb.qt4 AND gb.gtk. Should i create a separate package and make it a dependency of gb.gtk and gb.qt4 separately? I wanted to ask so all gambas packages out there follow the same standard. * Another thing, you should add gb.gui.base to the order file: comp/src/order Thanks! From jredrejo at ...82... Sat Oct 27 11:10:34 2012 From: jredrejo at ...82... (=?UTF-8?Q?Jos=C3=A9_Luis_Redrejo_Rodr=C3=ADguez?=) Date: Sat, 27 Oct 2012 11:10:34 +0200 Subject: [Gambas-devel] gb.gui.base packaging In-Reply-To: References: Message-ID: 2012/10/27 Sebastian Kulesz > Hi! > > The recent commit for the new gb.gui.base broke the daily builds ppa > packages. My first guess is that it should be included with the gb.gui > package, right? The thing is, gb.gui depends both on gb.qt4 AND > gb.gtk. Should i create a separate package and make it a dependency of > gb.gtk and gb.qt4 separately? > I wanted to ask so all gambas packages out there follow the same standard. > Hi Sebastian I'm afraid I don't know what you mean. Recent commit? Last time gambas3 packages where uploaded to Debian was in May, 24th. I'm not an Ubuntu user and don't know how the ppa packages are done, but I'm sure I haven't commited any package recently. > > * Another thing, you should add gb.gui.base to the order file: > comp/src/order > > We'll take a look to your advices to see if they fit with the gambas packaging guidelines and Debian Policy. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gambas at ...1... Sat Oct 27 12:02:45 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 27 Oct 2012 12:02:45 +0200 Subject: [Gambas-devel] gb.gui.base packaging In-Reply-To: References: Message-ID: <508BB145.2090301@...1...> Le 27/10/2012 06:30, Sebastian Kulesz a ?crit : > Hi! > > The recent commit for the new gb.gui.base broke the daily builds ppa > packages. My first guess is that it should be included with the gb.gui > package, right? The thing is, gb.gui depends both on gb.qt4 AND > gb.gtk. Should i create a separate package and make it a dependency of > gb.gtk and gb.qt4 separately? > I wanted to ask so all gambas packages out there follow the same standard. > > * Another thing, you should add gb.gui.base to the order file: comp/src/order > > Thanks! > I have committed the code that night, and didn't think about it. gb.gui DOES NOT depends on gb.qt4 AND gb.gtk. It depends on nothing, because either gb.qt4 or gb.gtk may not be installed. Of course, if one of them are installed, gb.gui is useless. Same comment for gb.gui.opengl. gb.gui.base is an hidden component that must be packaged separately, and that is explicitely loaded by gb.qt4 and gb.gtk, so gb.qt4 and gb.gtk must depend on it. I will update the wiki. Regards, -- Beno?t Minisini From gambas at ...1... Sat Oct 27 12:08:59 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 27 Oct 2012 12:08:59 +0200 Subject: [Gambas-devel] gb.gui.base packaging In-Reply-To: References: Message-ID: <508BB2BB.1000107@...1...> Le 27/10/2012 11:10, Jos? Luis Redrejo Rodr?guez a ?crit : > 2012/10/27 Sebastian Kulesz > >> Hi! >> >> The recent commit for the new gb.gui.base broke the daily builds ppa >> packages. My first guess is that it should be included with the gb.gui >> package, right? The thing is, gb.gui depends both on gb.qt4 AND >> gb.gtk. Should i create a separate package and make it a dependency of >> gb.gtk and gb.qt4 separately? >> I wanted to ask so all gambas packages out there follow the same standard. >> > > > Hi Sebastian > I'm afraid I don't know what you mean. > Recent commit? > Last time gambas3 packages where uploaded to Debian was in May, 24th. > I'm not an Ubuntu user and don't know how the ppa packages are done, but > I'm sure I haven't commited any package recently. > > > > > >> >> * Another thing, you should add gb.gui.base to the order file: >> comp/src/order >> >> > > We'll take a look to your advices to see if they fit with the gambas > packaging guidelines and Debian Policy. > Thanks. > Hi, Jos?. Nice to have news about you! :-) I have sent you a mail about Debian Gambas packaging (07-28-2012), which is broken, and so prevent any package made by the Gambas IDE to work on Debian and all Debian derivatives. Did you get it? The gambas binary packages structure is described in the wiki page "how to package gambas". By not following it, things do not work, and all Debian, Ubuntu, Mint... users have to compile Gambas by hand, or use extra binary packages made by people like Sebastian. Thanks. -- Beno?t Minisini -------------- next part -------------- An embedded message was scrubbed... From: =?ISO-8859-1?Q?Beno=EEt_Minisini?= Subject: The gambas3 packages are wrong Date: Sat, 28 Jul 2012 14:10:09 +0200 Size: 1079 URL: From jredrejo at ...176... Sat Oct 27 12:13:10 2012 From: jredrejo at ...176... (=?UTF-8?Q?Jos=C3=A9_Luis_Redrejo?=) Date: Sat, 27 Oct 2012 12:13:10 +0200 Subject: [Gambas-devel] gb.gui.base packaging In-Reply-To: <508BB2BB.1000107@...1...> References: <508BB2BB.1000107@...1...> Message-ID: 2012/10/27 Beno?t Minisini > Le 27/10/2012 11:10, Jos? Luis Redrejo Rodr?guez a ?crit : > > 2012/10/27 Sebastian Kulesz >> >> Hi! >>> >>> The recent commit for the new gb.gui.base broke the daily builds ppa >>> packages. My first guess is that it should be included with the gb.gui >>> package, right? The thing is, gb.gui depends both on gb.qt4 AND >>> gb.gtk. Should i create a separate package and make it a dependency of >>> gb.gtk and gb.qt4 separately? >>> I wanted to ask so all gambas packages out there follow the same >>> standard. >>> >>> >> >> Hi Sebastian >> I'm afraid I don't know what you mean. >> Recent commit? >> Last time gambas3 packages where uploaded to Debian was in May, 24th. >> I'm not an Ubuntu user and don't know how the ppa packages are done, but >> I'm sure I haven't commited any package recently. >> >> >> >> >> >> >>> * Another thing, you should add gb.gui.base to the order file: >>> comp/src/order >>> >>> >>> >> We'll take a look to your advices to see if they fit with the gambas >> packaging guidelines and Debian Policy. >> Thanks. >> >> > Hi, Jos?. > > Nice to have news about you! :-) > > I have sent you a mail about Debian Gambas packaging (07-28-2012), which > is broken, and so prevent any package made by the Gambas IDE to work on > Debian and all Debian derivatives. Did you get it? > Not, I haven't read that email. > > The gambas binary packages structure is described in the wiki page "how to > package gambas". By not following it, things do not work, and all Debian, > Ubuntu, Mint... users have to compile Gambas by hand, or use extra binary > packages made by people like Sebastian. > > Ok, I'll take a look at it , but I'm afraid I won't have much spare time until the last half of november. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gambas at ...1... Sat Oct 27 12:18:28 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 27 Oct 2012 12:18:28 +0200 Subject: [Gambas-devel] gb.gui.base packaging In-Reply-To: <508BB145.2090301@...1...> References: <508BB145.2090301@...1...> Message-ID: <508BB4F4.7000207@...1...> Le 27/10/2012 12:02, Beno?t Minisini a ?crit : > Le 27/10/2012 06:30, Sebastian Kulesz a ?crit : >> Hi! >> >> The recent commit for the new gb.gui.base broke the daily builds ppa >> packages. My first guess is that it should be included with the gb.gui >> package, right? The thing is, gb.gui depends both on gb.qt4 AND >> gb.gtk. Should i create a separate package and make it a dependency of >> gb.gtk and gb.qt4 separately? >> I wanted to ask so all gambas packages out there follow the same >> standard. >> >> * Another thing, you should add gb.gui.base to the order file: >> comp/src/order >> >> Thanks! >> > > I have committed the code that night, and didn't think about it. > > gb.gui DOES NOT depends on gb.qt4 AND gb.gtk. It depends on nothing, > because either gb.qt4 or gb.gtk may not be installed. Of course, if one > of them are installed, gb.gui is useless. > > Same comment for gb.gui.opengl. > > gb.gui.base is an hidden component that must be packaged separately, and > that is explicitely loaded by gb.qt4 and gb.gtk, so gb.qt4 and gb.gtk > must depend on it. > > I will update the wiki. > > Regards, > I have changed my mind about gb.gui.base packaging. As it is not a true component, but a Gambas part needed by GUI components, I will put it in the main package with gb.gui, gb.gui.opengl, gb.draw... Regards, -- Beno?t Minisini