From contact at ...694... Fri May 4 16:41:53 2012 From: contact at ...694... (Hamza Abdelkebir) Date: Fri, 04 May 2012 16:41:53 +0200 Subject: [Gambas-devel] Add progressbar and button to columnview Message-ID: <4FA3EAB1.4000904@...694...> Hi, Is it possible to add a progressbar and a button to 2 columns in a columnview Thanks for your help. Hamza From tobias at ...692... Fri May 4 18:08:07 2012 From: tobias at ...692... (tobi) Date: Fri, 4 May 2012 18:08:07 +0200 Subject: [Gambas-devel] Add progressbar and button to columnview In-Reply-To: <4FA3EAB1.4000904@...694...> References: <4FA3EAB1.4000904@...694...> Message-ID: <20120504160807.GB609@...693...> On Fri, 04 May 2012, Hamza Abdelkebir wrote: > Hi, > Is it possible to add a progressbar and a button to 2 columns in a > columnview > > Thanks for your help. > > Hamza > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > Well, if I remember correctly, the IDE uses controls in its Properties-Sidebar (like a ComboBox to select a value from predefined list, or a SpinBox for a predefined range, etc.). I think, they are normal controls which are just put on top of the GridView control, they are not inside but look as they were somehow built-in. I did something similar in a project and it was good, although I laughed at how clumsy I found that back then ;) But it's OK, it's all about the visual effect in graphics. BTW, you'll find the source in the Editor/Form/FProperty.class file in the IDE sources. Regards, Tobi From contact at ...694... Fri May 4 16:42:52 2012 From: contact at ...694... (contact at ...694...) Date: Fri, 04 May 2012 16:42:52 +0200 Subject: [Gambas-devel] progressbar and a button in a columnview Message-ID: <2c9ae4ccefb7d9f746b6a7733e1771f8@...102...> Hi, Is it possible to add a progressbar and a button to 2 columns in a columnview (gambas2) Thanks for your help. Hamza From hddfilestorage at ...176... Sat May 5 07:52:40 2012 From: hddfilestorage at ...176... (William Young) Date: Sat, 5 May 2012 00:52:40 -0500 Subject: [Gambas-devel] a quick hello, and some new tools. Message-ID: So I saw this awesome project, and decided that i just had to help in some way, I'm not much o a programmer except in languages based of of basic (and bash scripts). i noticed that you didn't have access to PowerPC machines, so im here to offer just that. i have 2 PowerMac G4s. 1. 400MHz 768MB ram 40GB HDD - OSX 10.4.11, with SSH access (and VNC if needed) 2. 800MHz 768MB ram 80GB HDD (40GB on / 40GB on /home) - Linux (Distro not chosen, its open for discussion), with SSH access I can offer full root access on both machines to people working on getting gambas working on PowerPC. neither computer is ever used by me so its not a big deal to me if there used by others. From tobias at ...692... Sun May 6 21:36:57 2012 From: tobias at ...692... (tobi) Date: Sun, 6 May 2012 21:36:57 +0200 Subject: [Gambas-devel] Unused signals to be sent Message-ID: <20120506193657.GE1507@...693...> Hi, I know that at least SIGUSR1 is needed by gbx3 or something to abort the current program. I am currently implementing an interface to the terminal driver to enable no-delay keyboard input. The experiences of my research were several manual reset button hits because the keyboard was screwed up when not properly cleaned up, which I didn't find nice and my computer neither - and of course I learned all that I need to implement that _correctly_ ;). Now, the cleanup works great whenever: * the program exits * an error occurs * the user hits ESC thrice during one second (emergency exit) (this enabled, however all users to screw up the program logic as it immediately exits the mode, the programmer chose for the application. But better than hardware reset if the program is misbehaving. I have to think about that...) I additionally, not only for consistency issues, want to be able to switch between virtual consoles when in this NoDelay mode. In another program I saw that the authors used signals they taught the vt driver to sent the program when a switch was requested from another vt to the one that program runs in and in the current vt, they take that under direct control of the program. Not that difficult but I need signals to be sent. What signal may I use? (The program I mentioned above uses SIGUSR1 and SIGUSR2 (for release and acquire) and I am not able to use these in Gambas, right? So which one are sure to use?) (And, Beno?t, wasn't there once the approach to register signal handlers using the interpreter API? I still need that to enable the terminal Resize event) Regards, Tobi From tobias at ...692... Sun May 6 23:23:27 2012 From: tobias at ...692... (tobi) Date: Sun, 6 May 2012 23:23:27 +0200 Subject: [Gambas-devel] Unused signals to be sent In-Reply-To: <20120506193657.GE1507@...693...> References: <20120506193657.GE1507@...693...> Message-ID: <20120506212327.GA613@...693...> On Sun, 06 May 2012, tobi wrote: > Hi, > > I know that at least SIGUSR1 is needed by gbx3 or something to abort the current program. I am > currently implementing an interface to the terminal driver to enable no-delay keyboard input. The > experiences of my research were several manual reset button hits because the keyboard was screwed > up when not properly cleaned up, which I didn't find nice and my computer neither - and of course > I learned all that I need to implement that _correctly_ ;). Now, the cleanup works great whenever: > * the program exits > * an error occurs > * the user hits ESC thrice during one second (emergency exit) (this enabled, however all users to > screw up the program logic as it immediately exits the mode, the programmer chose for the > application. But better than hardware reset if the program is misbehaving. I have to think about > that...) > > I additionally, not only for consistency issues, want to be able to switch between virtual consoles > when in this NoDelay mode. In another program I saw that the authors used signals they taught the vt > driver to sent the program when a switch was requested from another vt to the one that program runs > in and in the current vt, they take that under direct control of the program. Not that difficult > but I need signals to be sent. What signal may I use? (The program I mentioned above uses SIGUSR1 > and SIGUSR2 (for release and acquire) and I am not able to use these in Gambas, right? So which > one are sure to use?) > > (And, Beno?t, wasn't there once the approach to register signal handlers using the interpreter API? > I still need that to enable the terminal Resize event) > > Regards, > Tobi > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > Beno?t, another reason for the signal handler API (for some reason, I think that GB.Signal(int, void*) would do the job? Is that what you wanted to implement as we talked about the SIGWINCH handler in gb.ncurses? You mentioned pipes back then?): I just had a segfault trying a new feature and wished, that it could have been caught to properly shutdown the program, hence don't leave my keyboard in a state that I cannot operate with... Thank goodness, I have gpm in my daemons array now to reboot my machine softly... Gently await your reply. Regards, Tobi From gambas at ...1... Sun May 6 23:37:20 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 06 May 2012 23:37:20 +0200 Subject: [Gambas-devel] a quick hello, and some new tools. In-Reply-To: References: Message-ID: <4FA6EF10.9090001@...1...> Le 05/05/2012 07:52, William Young a ?crit : > So I saw this awesome project, and decided that i just had to help in > some way, I'm not much o a programmer except in languages based of of > basic (and bash scripts). i noticed that you didn't have access to > PowerPC machines, so im here to offer just that. i have 2 PowerMac > G4s. > > 1. 400MHz 768MB ram 40GB HDD - OSX 10.4.11, with SSH access (and VNC if needed) > 2. 800MHz 768MB ram 80GB HDD (40GB on / 40GB on /home) - Linux (Distro > not chosen, its open for discussion), with SSH access > > I can offer full root access on both machines to people working on > getting gambas working on PowerPC. neither computer is ever used by me > so its not a big deal to me if there used by others. > Thanks for your proposal. Fran?ois Gallo did an OSX port of Gambas 3, so I stopped trying to do the same thing on a distant machine. Only he can tell you how to make Gambas3 run on your Mac. I'm just trying to avoid Linux features that do not work on OSX when possible. Regards, -- Beno?t Minisini From gambas at ...1... Sun May 6 23:51:10 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 06 May 2012 23:51:10 +0200 Subject: [Gambas-devel] Unused signals to be sent In-Reply-To: <20120506193657.GE1507@...693...> References: <20120506193657.GE1507@...693...> Message-ID: <4FA6F24E.2010009@...1...> Le 06/05/2012 21:36, tobi a ?crit : > Hi, > > I know that at least SIGUSR1 is needed by gbx3 or something to abort the current program. Where did you see that? :-o The SIGUSR1 is handled by a debugged program, so that the IDE can tell him that the users has pressed the PAUSE button so that it stops on the next line. > I am > currently implementing an interface to the terminal driver to enable no-delay keyboard input. The > experiences of my research were several manual reset button hits because the keyboard was screwed > up when not properly cleaned up, which I didn't find nice and my computer neither - and of course > I learned all that I need to implement that _correctly_ ;). Now, the cleanup works great whenever: > * the program exits > * an error occurs > * the user hits ESC thrice during one second (emergency exit) (this enabled, however all users to > screw up the program logic as it immediately exits the mode, the programmer chose for the > application. But better than hardware reset if the program is misbehaving. I have to think about > that...) > Are terminal programs run in an X11 terminual emulator concerned too? > I additionally, not only for consistency issues, want to be able to switch between virtual consoles > when in this NoDelay mode. In another program I saw that the authors used signals they taught the vt > driver to sent the program when a switch was requested from another vt to the one that program runs > in and in the current vt, they take that under direct control of the program. Not that difficult > but I need signals to be sent. What signal may I use? (The program I mentioned above uses SIGUSR1 > and SIGUSR2 (for release and acquire) and I am not able to use these in Gambas, right? So which > one are sure to use?) I don't understand what you are talking about. If you want to *send* signal, no problem. Difficulty comes when you want to receive them. > > (And, Beno?t, wasn't there once the approach to register signal handlers using the interpreter API? > I still need that to enable the terminal Resize event) Here is the point: to receive signals reliably, you need a bunch of code that I want the interpreter to provide to the components through API. I didn't write this API yet, because it is more complex than I thought first. If you want more details, look at the "signalfd" system call that can solve most of my problems, but that is alas Linux specific, so I prefer not to use it! Regards, -- Beno?t Minisini From gambas at ...1... Sun May 6 23:57:45 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 06 May 2012 23:57:45 +0200 Subject: [Gambas-devel] Unused signals to be sent In-Reply-To: <20120506212327.GA613@...693...> References: <20120506193657.GE1507@...693...> <20120506212327.GA613@...693...> Message-ID: <4FA6F3D9.3010201@...1...> Le 06/05/2012 23:23, tobi a ?crit : > On Sun, 06 May 2012, tobi wrote: >> Hi, >> >> I know that at least SIGUSR1 is needed by gbx3 or something to abort the current program. I am >> currently implementing an interface to the terminal driver to enable no-delay keyboard input. The >> experiences of my research were several manual reset button hits because the keyboard was screwed >> up when not properly cleaned up, which I didn't find nice and my computer neither - and of course >> I learned all that I need to implement that _correctly_ ;). Now, the cleanup works great whenever: >> * the program exits >> * an error occurs >> * the user hits ESC thrice during one second (emergency exit) (this enabled, however all users to >> screw up the program logic as it immediately exits the mode, the programmer chose for the >> application. But better than hardware reset if the program is misbehaving. I have to think about >> that...) >> >> I additionally, not only for consistency issues, want to be able to switch between virtual consoles >> when in this NoDelay mode. In another program I saw that the authors used signals they taught the vt >> driver to sent the program when a switch was requested from another vt to the one that program runs >> in and in the current vt, they take that under direct control of the program. Not that difficult >> but I need signals to be sent. What signal may I use? (The program I mentioned above uses SIGUSR1 >> and SIGUSR2 (for release and acquire) and I am not able to use these in Gambas, right? So which >> one are sure to use?) >> >> (And, Beno?t, wasn't there once the approach to register signal handlers using the interpreter API? >> I still need that to enable the terminal Resize event) >> >> Regards, >> Tobi >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Gambas-devel mailing list >> Gambas-devel at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/gambas-devel >> > > Beno?t, > > another reason for the signal handler API (for some reason, I think that GB.Signal(int, void*) would > do the job? Is that what you wanted to implement as we talked about the SIGWINCH handler in > gb.ncurses? You mentioned pipes back then?): I just had a segfault trying a new feature and wished, > that it could have been caught to properly shutdown the program, hence don't leave my keyboard in a > state that I cannot operate with... Thank goodness, I have gpm in my daemons array now to reboot my > machine softly... > > Gently await your reply. > > Regards, > Tobi > You don't need to wait for the signal interpreter API to implement your own segfault handler if it is just for debugging purpose. -- Beno?t Minisini From tobias at ...692... Mon May 7 00:13:23 2012 From: tobias at ...692... (tobi) Date: Mon, 7 May 2012 00:13:23 +0200 Subject: [Gambas-devel] Unused signals to be sent In-Reply-To: <4FA6F24E.2010009@...1...> References: <20120506193657.GE1507@...693...> <4FA6F24E.2010009@...1...> Message-ID: <20120506221323.GB613@...693...> On Sun, 06 May 2012, Beno?t Minisini wrote: > Le 06/05/2012 21:36, tobi a ?crit : > > Hi, > > > > I know that at least SIGUSR1 is needed by gbx3 or something to abort the current program. > > Where did you see that? :-o > > The SIGUSR1 is handled by a debugged program, so that the IDE can tell > him that the users has pressed the PAUSE button so that it stops on the > next line. I read it somewhere or, what I deem less probable but not impossible, since I once was excited about gb.signal, noticed it - yes, for sure with a debugged program. I seem to have generalised that to Gambas interpreter... > > > I am > > currently implementing an interface to the terminal driver to enable no-delay keyboard input. The > > experiences of my research were several manual reset button hits because the keyboard was screwed > > up when not properly cleaned up, which I didn't find nice and my computer neither - and of course > > I learned all that I need to implement that _correctly_ ;). Now, the cleanup works great whenever: > > * the program exits > > * an error occurs > > * the user hits ESC thrice during one second (emergency exit) (this enabled, however all users to > > screw up the program logic as it immediately exits the mode, the programmer chose for the > > application. But better than hardware reset if the program is misbehaving. I have to think about > > that...) > > > > Are terminal programs run in an X11 terminual emulator concerned too? > I will try that under X the next days... It's very tricky: I need an fd on which I can use the console_ioctl(4)'s - another thing for the list of linux things, you want to avoid, maybe. Sorry, I read that statement just a few minutes ago and working on that NoDelay mode for a few days (idea came from Fabien who suggested to somehow bypass the keyboard repeat delay, on 15th April). The needed console_ioctl fd cannot even be a PTY and I don't think, X will let me do this easily but there will be a way around X restrictions by using X facilities, but I have to dig deeper into that stuff... (Hmm, reading that text, it doesn't sound that cool :| It's rather special purpose and the capability of switching to that mode can be tested by a property of Screen class so that the programmer can continue with a "delayed" mode which utilises ncurses directly. The NoDelay mode could be transparently use some X facility, if possible, that's no problem, I think) > > I additionally, not only for consistency issues, want to be able to switch between virtual consoles > > when in this NoDelay mode. In another program I saw that the authors used signals they taught the vt > > driver to sent the program when a switch was requested from another vt to the one that program runs > > in and in the current vt, they take that under direct control of the program. Not that difficult > > but I need signals to be sent. What signal may I use? (The program I mentioned above uses SIGUSR1 > > and SIGUSR2 (for release and acquire) and I am not able to use these in Gambas, right? So which > > one are sure to use?) > > I don't understand what you are talking about. If you want to *send* > signal, no problem. Difficulty comes when you want to receive them. > I instruct the vt driver to send signals to my process when switching to the vt controlled by my program, so I will receive signals. > > > > (And, Beno?t, wasn't there once the approach to register signal handlers using the interpreter API? > > I still need that to enable the terminal Resize event) > > Here is the point: to receive signals reliably, you need a bunch of code > that I want the interpreter to provide to the components through API. > > I didn't write this API yet, because it is more complex than I thought > first. If you want more details, look at the "signalfd" system call that > can solve most of my problems, but that is alas Linux specific, so I > prefer not to use it! Wow, thanks for pointing that out. Never heard of it but sounds rather useful! Sadly, it is not to be incorporated into Gambas... Don't worry, I have enough to do aside from that NoDelay mode... > > Regards, > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > Regards, Tobi From tobias at ...692... Mon May 7 19:36:42 2012 From: tobias at ...692... (tobi) Date: Mon, 7 May 2012 19:36:42 +0200 Subject: [Gambas-devel] Unused signals to be sent In-Reply-To: <20120506221323.GB613@...693...> References: <20120506193657.GE1507@...693...> <4FA6F24E.2010009@...1...> <20120506221323.GB613@...693...> Message-ID: <20120507173642.GC607@...693...> > > Are terminal programs run in an X11 terminual emulator concerned too? > > > > I will try that under X the next days... It's very tricky: I need an fd on which I can use the > console_ioctl(4)'s - another thing for the list of linux things, you want to avoid, maybe. Sorry, I > read that statement just a few minutes ago and working on that NoDelay mode for a few days (idea > came from Fabien who suggested to somehow bypass the keyboard repeat delay, on 15th April). The > needed console_ioctl fd cannot even be a PTY and I don't think, X will let me do this easily but > there will be a way around X restrictions by using X facilities, but I have to dig deeper into > that stuff... (Hmm, reading that text, it doesn't sound that cool :| It's rather special purpose and > the capability of switching to that mode can be tested by a property of Screen class so that the > programmer can continue with a "delayed" mode which utilises ncurses directly. The NoDelay mode > could be transparently use some X facility, if possible, that's no problem, I think) > I tried today, more accidentally, to use chvt(1) from within an X session. Result was "Couldn't get a file descriptor referring to the console". You'll find that error message in getfd.c in the kbd package. The routine in that file tries even more things than I do, in a similar way, so I have no hope with my current code to get such an fd under X. I'm not the least familiar with X events and stuff that might be promising in this case... Regards, Tobi From tobias at ...692... Mon May 7 20:15:24 2012 From: tobias at ...692... (tobi) Date: Mon, 7 May 2012 20:15:24 +0200 Subject: [Gambas-devel] Event design choice Message-ID: <20120507181524.GD607@...693...> Hi, embarrassing but I want to ask for advice: Regarding Window and Screen class meaning spheres (Screen being a terminal screen on which several Windows reside) in gb.ncurses, I already moved some and am going to move other symbols from the former to the latter - yippi, the component is experimental! ;) (this is entirely to unwind the whole sources and ease the addition of controls) Seriously, I'm stuck at one point: the Window class raises a Read event when data arrives at the input queue. Since there can be more Windows on one Screen which all share the same input queue (one per screen), there must be a Window that is _solely explicitly_ allowed to raise that Read event, in order to prevent concurrently raised events which will then issue, e.g., a blocking read call on the input queue because the multiple instances steal each other input... - it was like what I mentioned before this horror scenario and works. As now the Screen class develops, it could be better to unwind that mess and let only the Screen class raise a Read event, since there is one input queue per Screen - the point: simplification. On the other side, we can have multiple event names for the numerous Windows and set focus (the focused Window will raise Read event) on that one, we are currently operating on (think of: a dialog box), that means if I do DialogWindow.SetFocus(), the DialogBox_Read() event will be risen instead of the former, e.g., MainWindow_Read() event. That procedure could equally ease program flow for the cautious programmer as well as it will create spaghetti code for the unexperienced one. (The aforementioned effect could be achieved by using flags, too, of course...) That's my dilemma now. Has anyone remarks on either solution that may help me decide? I wonder if there could be a way to niftily implement a ShowModal() method... Regards, Tobi From gambas at ...1... Mon May 7 23:33:24 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Mon, 07 May 2012 23:33:24 +0200 Subject: [Gambas-devel] Event design choice In-Reply-To: <20120507181524.GD607@...693...> References: <20120507181524.GD607@...693...> Message-ID: <4FA83FA4.40107@...1...> Le 07/05/2012 20:15, tobi a ?crit : > Hi, > > embarrassing but I want to ask for advice: Regarding Window and Screen class meaning spheres (Screen > being a terminal screen on which several Windows reside) in gb.ncurses, I already moved some and am > going to move other symbols from the former to the latter - yippi, the component is experimental! ;) > (this is entirely to unwind the whole sources and ease the addition of controls) > Seriously, I'm stuck at one point: the Window class raises a Read event when data arrives at the > input queue. Since there can be more Windows on one Screen which all share the same input queue (one > per screen), there must be a Window that is _solely explicitly_ allowed to raise that Read event, in > order to prevent concurrently raised events which will then issue, e.g., a blocking read call on the > input queue because the multiple instances steal each other input... - it was like what I mentioned > before this horror scenario and works. > As now the Screen class develops, it could be better to unwind that mess and let only the Screen > class raise a Read event, since there is one input queue per Screen - the point: simplification. > On the other side, we can have multiple event names for the numerous Windows and set focus (the > focused Window will raise Read event) on that one, we are currently operating on (think of: a dialog > box), that means if I do DialogWindow.SetFocus(), the DialogBox_Read() event will be risen instead > of the former, e.g., MainWindow_Read() event. That procedure could equally ease program flow for the > cautious programmer as well as it will create spaghetti code for the unexperienced one. (The > aforementioned effect could be achieved by using flags, too, of course...) > > That's my dilemma now. Has anyone remarks on either solution that may help me decide? I wonder if > there could be a way to niftily implement a ShowModal() method... > > Regards, > Tobi > You can do both. :-) When there is something to read, you can do that: 1) Check if the Window having the focus has an event handler for the read event, with the GB.CanRaise() API. 2) If it has the event handler, let the window raise the event. 3) Otherwise, let the screen raise the event. What do you think about that? -- Beno?t Minisini From tobias at ...692... Tue May 8 17:02:15 2012 From: tobias at ...692... (tobi) Date: Tue, 8 May 2012 17:02:15 +0200 Subject: [Gambas-devel] Event design choice In-Reply-To: <4FA83FA4.40107@...1...> References: <20120507181524.GD607@...693...> <4FA83FA4.40107@...1...> Message-ID: <20120508150215.GC605@...693...> On Mon, 07 May 2012, Beno?t Minisini wrote: > Le 07/05/2012 20:15, tobi a ?crit : > > Hi, > > > > embarrassing but I want to ask for advice: Regarding Window and Screen class meaning spheres (Screen > > being a terminal screen on which several Windows reside) in gb.ncurses, I already moved some and am > > going to move other symbols from the former to the latter - yippi, the component is experimental! ;) > > (this is entirely to unwind the whole sources and ease the addition of controls) > > Seriously, I'm stuck at one point: the Window class raises a Read event when data arrives at the > > input queue. Since there can be more Windows on one Screen which all share the same input queue (one > > per screen), there must be a Window that is _solely explicitly_ allowed to raise that Read event, in > > order to prevent concurrently raised events which will then issue, e.g., a blocking read call on the > > input queue because the multiple instances steal each other input... - it was like what I mentioned > > before this horror scenario and works. > > As now the Screen class develops, it could be better to unwind that mess and let only the Screen > > class raise a Read event, since there is one input queue per Screen - the point: simplification. > > On the other side, we can have multiple event names for the numerous Windows and set focus (the > > focused Window will raise Read event) on that one, we are currently operating on (think of: a dialog > > box), that means if I do DialogWindow.SetFocus(), the DialogBox_Read() event will be risen instead > > of the former, e.g., MainWindow_Read() event. That procedure could equally ease program flow for the > > cautious programmer as well as it will create spaghetti code for the unexperienced one. (The > > aforementioned effect could be achieved by using flags, too, of course...) > > > > That's my dilemma now. Has anyone remarks on either solution that may help me decide? I wonder if > > there could be a way to niftily implement a ShowModal() method... > > > > Regards, > > Tobi > > > > You can do both. :-) > > When there is something to read, you can do that: > > 1) Check if the Window having the focus has an event handler for the > read event, with the GB.CanRaise() API. > > 2) If it has the event handler, let the window raise the event. > > 3) Otherwise, let the screen raise the event. > > What do you think about that? > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > Sounds like it complicates things even more ;) Actually a good idea, for both parties. Although, it intermixes Window and Screen class again... Of course, this is better than raising with a default "Window" event name... I don't know if I'm content with that, I hoped to get rid of that focused Window but it simplified that much. However, good to learn new things every day (GB.CanRaise()), but I have to set up this idea a little further: I watch the input queue associated with a screen using my (not already commited) input module which then would utilise the @focused window and something like an @active screen (for now, there is only one auto-creatable screen but that will change as needed). The input module first checks if the @focused window has an event handler (of course it has, since I will raise an error if a Window.SetFocus() is done on a window which has no event name - with that in mind, it sounds not that confusing anymore!) and if it is NULL, the screen raises the event. OK, convinced, I have to rewrite the documentation anyway :) Great idea, actually. Regards, Tobi From gambas at ...1... Tue May 8 17:38:43 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Tue, 08 May 2012 17:38:43 +0200 Subject: [Gambas-devel] Event design choice In-Reply-To: <20120508150215.GC605@...693...> References: <20120507181524.GD607@...693...> <4FA83FA4.40107@...1...> <20120508150215.GC605@...693...> Message-ID: <4FA93E03.9090805@...1...> Le 08/05/2012 17:02, tobi a ?crit : > > Sounds like it complicates things even more ;) Actually a good idea, for both parties. Although, it > intermixes Window and Screen class again... Of course, this is better than raising with a default > "Window" event name... I don't know if I'm content with that, I hoped to get rid of that focused > Window but it simplified that much. However, good to learn new things every day (GB.CanRaise()), but > I have to set up this idea a little further: I watch the input queue associated with a screen using > my (not already commited) input module which then would utilise the @focused window and something > like an @active screen (for now, there is only one auto-creatable screen but that will change as > needed). The input module first checks if the @focused window has an event handler (of course it > has, since I will raise an error if a Window.SetFocus() is done on a window which has no event name > - with that in mind, it sounds not that confusing anymore!) and if it is NULL, the screen raises the > event. > OK, convinced, I have to rewrite the documentation anyway :) > > Great idea, actually. > > Regards, > Tobi > Hi, In revision #4721, you have two new interpreter APIs: GB.Signal.Register: GB_SIGNAL_CALLBACK *GB.Signal.Register(int signum, void (*callback)(int, intptr_t), intptr_t data) This function asks Gambas to call the 'callback' function each time the 'signum' signal is received. 'data' is a pointer that will be passed as-is to the 'callback' function as second argument. The first one being the signal number. A pointer is returned, that you must use to unregister the signal callback once you are done with it. GB.Signal.Unregister: void GB.Signal.Unregister(GB_SIGNAL_CALLBACK *callback); The callback is called in the context of the event loop, not in the context of the signal handler. So you can do what you want in these callbacks: raise events for example. Being the first one who will use that API, you will tell me if it works! Regards, -- Beno?t Minisini From tobias at ...692... Sat May 12 21:05:37 2012 From: tobias at ...692... (tobi) Date: Sat, 12 May 2012 21:05:37 +0200 Subject: [Gambas-devel] Early auto-instance Message-ID: <20120512190537.GJ606@...693...> Hi, I have a compilation unit that provides a function which in turn depends on the state of an object. The default object is the auto-instance of a class (it is just a simple buffered output) but the auto-instance of a class seems to be created on-the-fly when first requested. Now this auto-instance may not be created normally before I need to take actions depending on its state (call the exported function by another piece of code)... I thought of having GB.AutoCreate(GB.FindClass("Screen"), 0); called from within the GB_INIT() of my component to ensure that there exists a valid object. The program works now but I get a segfault: Program received signal SIGSEGV, Segmentation fault. MEMORY_clear_cache () at ../share/gb_alloc_temp.h:96 96 next = *((void **)ptr); (gdb) print ptr $1 = (void *) 0x123 when the program is going to exit. Is there somehting, I should keep in mind when manually creating this auto-instance? Another point: This is provisional only; I will have to rewrite it anyway when I make Screen a true creatable class. So there is my next question regarding coding style in gambas: Is it common to save a pointer to another gambas object (the parent object) when creating? This would solve the auto-instance problem as my Screen class (which is to auto-create earlily) is reference during instanciation of the Window object and the latter is the object which calls the function in question (which depends on the active Screen class to enable buffered output on screen). That sounds tricky, so I wanted to ask if it is considered good style in gambas or if there are other ways to do it. The place I knew to look for was the gb.qt4 component which delegates the parent object stuff to qt itself... Regards, Tobi From tobias at ...692... Sat May 12 21:14:04 2012 From: tobias at ...692... (tobi) Date: Sat, 12 May 2012 21:14:04 +0200 Subject: [Gambas-devel] Early auto-instance In-Reply-To: <20120512190537.GJ606@...693...> References: <20120512190537.GJ606@...693...> Message-ID: <20120512191404.GK606@...693...> On Sat, 12 May 2012, tobi wrote: > Hi, > > I have a compilation unit that provides a function which in turn depends on the state of an object. > The default object is the auto-instance of a class (it is just a simple buffered output) but the > auto-instance of a class seems to be created on-the-fly when first requested. Now this auto-instance > may not be created normally before I need to take actions depending on its state (call the exported > function by another piece of code)... I thought of having > > GB.AutoCreate(GB.FindClass("Screen"), 0); > > called from within the GB_INIT() of my component to ensure that there exists a valid object. The > program works now but I get a segfault: > > Program received signal SIGSEGV, Segmentation fault. > MEMORY_clear_cache () at ../share/gb_alloc_temp.h:96 > 96 next = *((void **)ptr); > (gdb) print ptr > $1 = (void *) 0x123 > > when the program is going to exit. Is there somehting, I should keep in mind when manually creating > this auto-instance? > > Another point: This is provisional only; I will have to rewrite it anyway when I make Screen a true > creatable class. So there is my next question regarding coding style in gambas: Is it common to save > a pointer to another gambas object (the parent object) when creating? This would solve the > auto-instance problem as my Screen class (which is to auto-create earlily) is reference during > instanciation of the Window object and the latter is the object which calls the function in question > (which depends on the active Screen class to enable buffered output on screen). That sounds tricky, > so I wanted to ask if it is considered good style in gambas or if there are other ways to do it. The > place I knew to look for was the gb.qt4 component which delegates the parent object stuff to qt > itself... > > Regards, > Tobi > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > Oops! I also auto-create a Window object so the parent is to be optional... This solution wouldn't prevent me from manually auto-creating the Screen class. I tend to remove the GB_AUTO_CREATABLE() statement from both descriptions :/ From gambas at ...1... Sat May 12 22:38:50 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 12 May 2012 22:38:50 +0200 Subject: [Gambas-devel] Early auto-instance In-Reply-To: <20120512191404.GK606@...693...> References: <20120512190537.GJ606@...693...> <20120512191404.GK606@...693...> Message-ID: <4FAECA5A.6030706@...1...> Le 12/05/2012 21:14, tobi a ?crit : > On Sat, 12 May 2012, tobi wrote: >> Hi, >> >> I have a compilation unit that provides a function which in turn depends on the state of an object. >> The default object is the auto-instance of a class (it is just a simple buffered output) but the >> auto-instance of a class seems to be created on-the-fly when first requested. Now this auto-instance >> may not be created normally before I need to take actions depending on its state (call the exported >> function by another piece of code)... I thought of having >> >> GB.AutoCreate(GB.FindClass("Screen"), 0); >> >> called from within the GB_INIT() of my component to ensure that there exists a valid object. The >> program works now but I get a segfault: >> >> Program received signal SIGSEGV, Segmentation fault. >> MEMORY_clear_cache () at ../share/gb_alloc_temp.h:96 >> 96 next = *((void **)ptr); >> (gdb) print ptr >> $1 = (void *) 0x123 >> >> when the program is going to exit. Is there somehting, I should keep in mind when manually creating >> this auto-instance? GB_INIT() is called before the component classes are registered, so GB.FindClass("Screen") should return NULL. So this is not the good place for that! The goal of having auto-creatable class is the ability of using the class name as the default object of a class. That's all. >> >> Another point: This is provisional only; I will have to rewrite it anyway when I make Screen a true >> creatable class. GB_AUTO_CREATABLE() is for true creatable class, even if you add GB_NOT_CREATABLE(), that just means that we cannot use the New operator to instantiate the class in code. But the class keeps being creatable internally. A class that is not creatable class has GB_VIRTUAL(), or a size of 0 in the GB_DECLARE() statement and only static methods. >> So there is my next question regarding coding style in gambas: Is it common to save >> a pointer to another gambas object (the parent object) when creating? This would solve the >> auto-instance problem as my Screen class (which is to auto-create earlily) is reference during >> instanciation of the Window object and the latter is the object which calls the function in question >> (which depends on the active Screen class to enable buffered output on screen). Of course you can have child/parent relationship through object pointers, provided that you use GB.Ref() and GB.Unref() effectively. But why do you need to instanciate the default Screen class object early? It seems weird to me... >> That sounds tricky, >> so I wanted to ask if it is considered good style in gambas or if there are other ways to do it. The >> place I knew to look for was the gb.qt4 component which delegates the parent object stuff to qt >> itself... >> >> Regards, >> Tobi >> > > Oops! > I also auto-create a Window object so the parent is to be optional... This solution wouldn't prevent > me from manually auto-creating the Screen class. I tend to remove the GB_AUTO_CREATABLE() statement > from both descriptions :/ > -- Beno?t Minisini From tobias at ...692... Sat May 12 23:36:53 2012 From: tobias at ...692... (tobi) Date: Sat, 12 May 2012 23:36:53 +0200 Subject: [Gambas-devel] Early auto-instance In-Reply-To: <4FAECA5A.6030706@...1...> References: <20120512190537.GJ606@...693...> <20120512191404.GK606@...693...> <4FAECA5A.6030706@...1...> Message-ID: <20120512213653.GM606@...693...> On Sat, 12 May 2012, Beno?t Minisini wrote: > Le 12/05/2012 21:14, tobi a ?crit : > > On Sat, 12 May 2012, tobi wrote: > >> Hi, > >> > >> I have a compilation unit that provides a function which in turn depends on the state of an object. > >> The default object is the auto-instance of a class (it is just a simple buffered output) but the > >> auto-instance of a class seems to be created on-the-fly when first requested. Now this auto-instance > >> may not be created normally before I need to take actions depending on its state (call the exported > >> function by another piece of code)... I thought of having > >> > >> GB.AutoCreate(GB.FindClass("Screen"), 0); > >> > >> called from within the GB_INIT() of my component to ensure that there exists a valid object. The > >> program works now but I get a segfault: > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> MEMORY_clear_cache () at ../share/gb_alloc_temp.h:96 > >> 96 next = *((void **)ptr); > >> (gdb) print ptr > >> $1 = (void *) 0x123 > >> > >> when the program is going to exit. Is there somehting, I should keep in mind when manually creating > >> this auto-instance? > > GB_INIT() is called before the component classes are registered, so > GB.FindClass("Screen") should return NULL. So this is not the good place > for that! > > The goal of having auto-creatable class is the ability of using the > class name as the default object of a class. That's all. > > >> > >> Another point: This is provisional only; I will have to rewrite it anyway when I make Screen a true > >> creatable class. > > GB_AUTO_CREATABLE() is for true creatable class, even if you add > GB_NOT_CREATABLE(), that just means that we cannot use the New operator > to instantiate the class in code. But the class keeps being creatable > internally. When I said "true creatable", I meant that for now only the auto-instance could be used as other objects created via New would entirely confuse the component - that's what I'm going to correct and afterwards call it "true creatable" ;) Sorry for the misunderstanding... > > A class that is not creatable class has GB_VIRTUAL(), or a size of 0 in > the GB_DECLARE() statement and only static methods. > > >> So there is my next question regarding coding style in gambas: Is it common to save > >> a pointer to another gambas object (the parent object) when creating? This would solve the > >> auto-instance problem as my Screen class (which is to auto-create earlily) is reference during > >> instanciation of the Window object and the latter is the object which calls the function in question > >> (which depends on the active Screen class to enable buffered output on screen). > > Of course you can have child/parent relationship through object > pointers, provided that you use GB.Ref() and GB.Unref() effectively. > > But why do you need to instanciate the default Screen class object > early? It seems weird to me... Yes, well, GB.Ref() and .Unref() are used for reference counting, right? I don't have to worry about anything, only the balance of my calls to either of them? Consider the following code: .src/MMain.module --8<--------------- ' Gambas module file Public Sub Main() Window.Print("test") End --8<--------------- This would print text and then exit. Printing text involves a screen refresh - as the name suggests, I moved the corresponding routine to the Screen class (formerly known as WINDOW_refresh, WINDOW_real_refresh and macros), the buffering mechanism, too. But at the time, I call Window.Print(), there is no Screen class available of which I can check buffer settings. For future, when Screen becomes usable as a creatable class (s.a.), it would be convenient to associate Windows to the Screen they are printing their data on so this is required. I could have static void SCREEN_refresh(void *_object) { if (!THIS) { SCREEN_real_refresh(); return; } if (THIS->buffered) { ... } But I would likely need the Screen auto-instance somewhere else. If it is so complicated, my approach almost appears like a design failure to me... > > >> That sounds tricky, > >> so I wanted to ask if it is considered good style in gambas or if there are other ways to do it. The > >> place I knew to look for was the gb.qt4 component which delegates the parent object stuff to qt > >> itself... > >> > >> Regards, > >> Tobi > >> > > > > Oops! > > I also auto-create a Window object so the parent is to be optional... This solution wouldn't prevent > > me from manually auto-creating the Screen class. I tend to remove the GB_AUTO_CREATABLE() statement > > from both descriptions :/ > > > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > From tobias at ...692... Sat May 12 23:46:11 2012 From: tobias at ...692... (tobi) Date: Sat, 12 May 2012 23:46:11 +0200 Subject: [Gambas-devel] Early auto-instance In-Reply-To: <20120512213653.GM606@...693...> References: <20120512190537.GJ606@...693...> <20120512191404.GK606@...693...> <4FAECA5A.6030706@...1...> <20120512213653.GM606@...693...> Message-ID: <20120512214611.GN606@...693...> On Sat, 12 May 2012, tobi wrote: > On Sat, 12 May 2012, Beno?t Minisini wrote: > > Le 12/05/2012 21:14, tobi a ?crit : > > > On Sat, 12 May 2012, tobi wrote: > > >> Hi, > > >> > > >> I have a compilation unit that provides a function which in turn depends on the state of an object. > > >> The default object is the auto-instance of a class (it is just a simple buffered output) but the > > >> auto-instance of a class seems to be created on-the-fly when first requested. Now this auto-instance > > >> may not be created normally before I need to take actions depending on its state (call the exported > > >> function by another piece of code)... I thought of having > > >> > > >> GB.AutoCreate(GB.FindClass("Screen"), 0); > > >> > > >> called from within the GB_INIT() of my component to ensure that there exists a valid object. The > > >> program works now but I get a segfault: > > >> > > >> Program received signal SIGSEGV, Segmentation fault. > > >> MEMORY_clear_cache () at ../share/gb_alloc_temp.h:96 > > >> 96 next = *((void **)ptr); > > >> (gdb) print ptr > > >> $1 = (void *) 0x123 > > >> > > >> when the program is going to exit. Is there somehting, I should keep in mind when manually creating > > >> this auto-instance? > > > > GB_INIT() is called before the component classes are registered, so > > GB.FindClass("Screen") should return NULL. So this is not the good place > > for that! > > > > The goal of having auto-creatable class is the ability of using the > > class name as the default object of a class. That's all. > > > > >> > > >> Another point: This is provisional only; I will have to rewrite it anyway when I make Screen a true > > >> creatable class. > > > > GB_AUTO_CREATABLE() is for true creatable class, even if you add > > GB_NOT_CREATABLE(), that just means that we cannot use the New operator > > to instantiate the class in code. But the class keeps being creatable > > internally. > > When I said "true creatable", I meant that for now only the auto-instance could be used as other > objects created via New would entirely confuse the component - that's what I'm going to correct and > afterwards call it "true creatable" ;) Sorry for the misunderstanding... > > > > > A class that is not creatable class has GB_VIRTUAL(), or a size of 0 in > > the GB_DECLARE() statement and only static methods. > > > > >> So there is my next question regarding coding style in gambas: Is it common to save > > >> a pointer to another gambas object (the parent object) when creating? This would solve the > > >> auto-instance problem as my Screen class (which is to auto-create earlily) is reference during > > >> instanciation of the Window object and the latter is the object which calls the function in question > > >> (which depends on the active Screen class to enable buffered output on screen). > > > > Of course you can have child/parent relationship through object > > pointers, provided that you use GB.Ref() and GB.Unref() effectively. > > > > But why do you need to instanciate the default Screen class object > > early? It seems weird to me... > > Yes, well, GB.Ref() and .Unref() are used for reference counting, right? I don't have to worry about > anything, only the balance of my calls to either of them? > > Consider the following code: > > .src/MMain.module > --8<--------------- > ' Gambas module file > > Public Sub Main() > Window.Print("test") > End > --8<--------------- > > This would print text and then exit. Printing text involves a screen refresh - as the name suggests, > I moved the corresponding routine to the Screen class (formerly known as WINDOW_refresh, > WINDOW_real_refresh and macros), the buffering mechanism, too. But at the time, I call > Window.Print(), there is no Screen class available of which I can check buffer settings. > For future, when Screen becomes usable as a creatable class (s.a.), it would be convenient to > associate Windows to the Screen they are printing their data on so this is required. I could have > > static void SCREEN_refresh(void *_object) > { > if (!THIS) { > SCREEN_real_refresh(); > return; > } > if (THIS->buffered) { > ... > } > > But I would likely need the Screen auto-instance somewhere else. > > If it is so complicated, my approach almost appears like a design failure to me... > > > > > >> That sounds tricky, > > >> so I wanted to ask if it is considered good style in gambas or if there are other ways to do it. The > > >> place I knew to look for was the gb.qt4 component which delegates the parent object stuff to qt > > >> itself... > > >> > > >> Regards, > > >> Tobi > > >> > > > > > > Oops! > > > I also auto-create a Window object so the parent is to be optional... This solution wouldn't prevent > > > me from manually auto-creating the Screen class. I tend to remove the GB_AUTO_CREATABLE() statement > > > from both descriptions :/ > > > > > > > -- > > Beno?t Minisini > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Gambas-devel mailing list > > Gambas-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gambas-devel > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > I would go like this: - Window not auto-creatable, parent Screen is mandatory for Window constructor - Screen auto-creatable It means that the user will have to create a Window to paint on first in every gb.ncurses program. If I would make the parent parameter optional, I would have to use a default screen and then it would be the same issue as above, I would need the auto-instance of Screen for this... From gambas at ...1... Sat May 12 23:58:51 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 12 May 2012 23:58:51 +0200 Subject: [Gambas-devel] Early auto-instance In-Reply-To: <20120512214611.GN606@...693...> References: <20120512190537.GJ606@...693...> <20120512191404.GK606@...693...> <4FAECA5A.6030706@...1...> <20120512213653.GM606@...693...> <20120512214611.GN606@...693...> Message-ID: <4FAEDD1B.40907@...1...> Le 12/05/2012 23:46, tobi a ?crit : > > I would go like this: > > - Window not auto-creatable, parent Screen is mandatory for Window constructor > - Screen auto-creatable > > It means that the user will have to create a Window to paint on first in every gb.ncurses program. > If I would make the parent parameter optional, I would have to use a default screen and then it > would be the same issue as above, I would need the auto-instance of Screen for this... > You don't need an existing Gambas Screen object to refresh the screen. You must make a split between the Screen class (which is an interface) and the real routines doing the job. I mean: if Window.Print() needs a screen refreshing, then the Window.Print() implementation method will call an internal helper function that refreshes the screen. The Screen.Refresh() method will call the same internal function. But a Window object should not depend on the existence of the Screen Gambas object. Am I clear? -- Beno?t Minisini From tobias at ...692... Sun May 13 00:07:44 2012 From: tobias at ...692... (tobi) Date: Sun, 13 May 2012 00:07:44 +0200 Subject: [Gambas-devel] Early auto-instance In-Reply-To: <4FAEDD1B.40907@...1...> References: <20120512190537.GJ606@...693...> <20120512191404.GK606@...693...> <4FAECA5A.6030706@...1...> <20120512213653.GM606@...693...> <20120512214611.GN606@...693...> <4FAEDD1B.40907@...1...> Message-ID: <20120512220744.GO606@...693...> On Sat, 12 May 2012, Beno?t Minisini wrote: > Le 12/05/2012 23:46, tobi a ?crit : > > > > I would go like this: > > > > - Window not auto-creatable, parent Screen is mandatory for Window constructor > > - Screen auto-creatable > > > > It means that the user will have to create a Window to paint on first in every gb.ncurses program. > > If I would make the parent parameter optional, I would have to use a default screen and then it > > would be the same issue as above, I would need the auto-instance of Screen for this... > > > > You don't need an existing Gambas Screen object to refresh the screen. > > You must make a split between the Screen class (which is an interface) > and the real routines doing the job. > > I mean: if Window.Print() needs a screen refreshing, then the > Window.Print() implementation method will call an internal helper > function that refreshes the screen. > > The Screen.Refresh() method will call the same internal function. But a > Window object should not depend on the existence of the Screen Gambas > object. > > Am I clear? > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > All clear, that's all clear, but: routines in the Window object want to refresh the screen. Screen refresh may be buffered. Buffering is handled via the Screen class that represents the entire screen. I need a valid Screen object to determine the buffering settings (in this example; I can spot input stuff that will go through the Screen class, too, as said in another thread recently). Regards, Tobi From gambas at ...1... Sun May 13 00:20:51 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 13 May 2012 00:20:51 +0200 Subject: [Gambas-devel] Early auto-instance In-Reply-To: <20120512220744.GO606@...693...> References: <20120512190537.GJ606@...693...> <20120512191404.GK606@...693...> <4FAECA5A.6030706@...1...> <20120512213653.GM606@...693...> <20120512214611.GN606@...693...> <4FAEDD1B.40907@...1...> <20120512220744.GO606@...693...> Message-ID: <4FAEE243.7040706@...1...> Le 13/05/2012 00:07, tobi a ?crit : > > All clear, that's all clear, but: routines in the Window object want to refresh the screen. Screen > refresh may be buffered. Buffering is handled via the Screen class that represents the entire > screen. I need a valid Screen object to determine the buffering settings (in this example; I can > spot input stuff that will go through the Screen class, too, as said in another thread recently). > > Regards, > Tobi > I guess I don't have the latest source code? I meant that you don't need the Screen Gambas object as soon as you split the interface (the Screen object) from the implementation. The implementation always exists, even if the Screen default object has not been instanciated yet. -- Beno?t Minisini From tobias at ...692... Sun May 13 00:36:21 2012 From: tobias at ...692... (tobi) Date: Sun, 13 May 2012 00:36:21 +0200 Subject: [Gambas-devel] Early auto-instance In-Reply-To: <4FAEE243.7040706@...1...> References: <20120512190537.GJ606@...693...> <20120512191404.GK606@...693...> <4FAECA5A.6030706@...1...> <20120512213653.GM606@...693...> <20120512214611.GN606@...693...> <4FAEDD1B.40907@...1...> <20120512220744.GO606@...693...> <4FAEE243.7040706@...1...> Message-ID: <20120512223621.GP606@...693...> On Sun, 13 May 2012, Beno?t Minisini wrote: > Le 13/05/2012 00:07, tobi a ?crit : > > > > All clear, that's all clear, but: routines in the Window object want to refresh the screen. Screen > > refresh may be buffered. Buffering is handled via the Screen class that represents the entire > > screen. I need a valid Screen object to determine the buffering settings (in this example; I can > > spot input stuff that will go through the Screen class, too, as said in another thread recently). > > > > Regards, > > Tobi > > > > I guess I don't have the latest source code? > > I meant that you don't need the Screen Gambas object as soon as you > split the interface (the Screen object) from the implementation. > > The implementation always exists, even if the Screen default object has > not been instanciated yet. > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > My last commit was relatively long ago. I changed some things and will continue as soon as this issue is corrected... (Do you want to take a look? I would have to commit a totally broken component) Formerly, it was like: each Window contained its own buffering settings and a refresh was done by the Windows themselves so everything was there. That however affected the whole screen. This behaviour was misleading so I decided to move the buffering settings where they belong: the Screen class. I have SCREEN_refresh() and SCREEN_real_refresh() which are just the same as the corresponding WINDOW_ functions (respecting buffering settings and doing a plain refresh, respectively) that can be visited in the current revision. Normally, all interface functions call the SCREEN_refresh() function when they are done to update the screen. It is intended that this function checks for buffering settings and only update when the Screen is unbuffered. If there is no Screen, the function cannot work. Hence my proposition to include a parent Screen which can be passed as an argument to the SCREEN_refresh() routine. But if I do so, the parent Screen must be a mandatory argument to the Window constructor to ensure, it already exists and consequently, I can say bye-bye to the auto-creatable Window... I hope to not be so confusing this time. Regards, Tobi From ron at ...572... Sat May 19 17:00:00 2012 From: ron at ...572... (Ron) Date: Sat, 19 May 2012 17:00:00 +0200 Subject: [Gambas-devel] Gambas3 latest trunk xmlrpc broken Message-ID: xmlrpc server is broken. Ok so the xmlrpc client/server code which I painfully made working in Gambas2 is broken in Gambas3 latest revision. I'm not happy, who did this? ;-) XMLDBG : (reader.cpp:91) ?l?ment de texte termin? : zwave.setids XMLDBG : (reader.cpp:91) ?l?ment de texte termin? : 69670 XMLDBG : (reader.cpp:91) ?l?ment de texte termin? : 1 Tools.Find.24: #13: Null object 1: MiniServer.ProcessQuery.185 2: MiniServer.Socket_Read.312 Would also be nice if the error msgs stay in English, not France. Please fix if you know whats changed? I cannot use Gambas3 at all for my rather big project anymore. Regards, Ron_2nd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gambas at ...1... Sun May 20 18:56:02 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 20 May 2012 18:56:02 +0200 Subject: [Gambas-devel] [Gambas-user] Error in Left$ and Mid$ functions to the gb.ncurses component In-Reply-To: <20120520164353.GA614@...693...> References: <4FB90332.30305@...1...> <20120520164353.GA614@...693...> Message-ID: <4FB92222.4060208@...1...> Le 20/05/2012 18:43, tobi a ?crit : > > So my question bounces to Beno?t: It's said in the docs that the three string functions used above > are optimised so that they don't duplicate strings. Does that mean or is it a general fact that I > cannot rely on the STRING() macro to extract a NUL-terminated string from a given GB_STRING > argument? At least there doesn't seem to be a NUL byte which causes the component to print > everything that follows until the end of the original string... > Brief explanation and after lunch, it's done. > > Regards, > Tobi > No problem, I never told you how it works, so you couldn't guess! Gambas strings are not C strings (i.e. null byte terminated), but a combination of a string pointer (char *) and a length. To get the string pointer from a string argument, you must use the STRING() macro, but you already knew. To get the length of a string argument, you must use the LENGTH() macro. Now, the problem is that sometimes you cannot deal with such strings, and need a C-string. Hopefully, the interpreter provides the GB.ToZeroString() API that takes the string argument (through the ARG() macro) and returns a temporary C-string that will be automatically freed later. So, either you have: BEGIN_METHOD(MyMethod, GB_STRING arg) my_function(STRING(arg), LENGTH(arg)); END_METHOD or (if you really need a C-string): BEGIN_METHOD(MyMethod, GB_STRING arg) my_function(GB.ToZeroString(ARG(arg))); END_METHOD Regards, -- Beno?t Minisini From tobias at ...692... Sun May 20 22:21:33 2012 From: tobias at ...692... (tobi) Date: Sun, 20 May 2012 22:21:33 +0200 Subject: [Gambas-devel] Hooking the event loop Message-ID: <20120520202133.GF614@...693...> Hi, I saw in gambas.h that I'm able to install a hook for the event loop. This simply is a function to be called by the native event loop, as I saw in gb.qt4, right? Is there any policy to respect when I install such a hook (like saving the former hook and calling it, too to not turn off any essential attributes of other components)? Of course, I wouldn't fiddle around with that without a reason: I have a module that will wait for a key press and from then on continuously raise events until a key release occurs. I need a point where it makes sense to install a function that periodically dispatches that event. You see, it is handled by logic so I have no fd or something to GB.Watch()... Regards, Tobi From gambas.fr at ...176... Mon May 21 08:10:13 2012 From: gambas.fr at ...176... (Fabien Bodard) Date: Mon, 21 May 2012 08:10:13 +0200 Subject: [Gambas-devel] Gambas3 latest trunk xmlrpc broken In-Reply-To: References: Message-ID: 2012/5/19 Ron > xmlrpc server is broken. > > Ok so the xmlrpc client/server code which I painfully made working in > Gambas2 is broken in Gambas3 latest revision. > > I'm not happy, who did this? ;-) > > XMLDBG : (reader.cpp:91) ?l?ment de texte termin? : zwave.setids > XMLDBG : (reader.cpp:91) ?l?ment de texte termin? : 69670 > XMLDBG : (reader.cpp:91) ?l?ment de texte termin? : 1 > Tools.Find.24: #13: Null object > 1: MiniServer.ProcessQuery.185 > 2: MiniServer.Socket_Read.312 > > > Would also be nice if the error msgs stay in English, not France. > > Please fix if you know whats changed? > I cannot use Gambas3 at all for my rather big project anymore. > > Regards, > Ron_2nd. > It's Adrien Prokopowicz... he have rewritted the component xml from scratch. I have send him your message, i don't know if he is registered on this mailing list. -- Fabien Bodard -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrien.prokopowicz at ...176... Mon May 21 12:40:10 2012 From: adrien.prokopowicz at ...176... (Adrien Prokopowicz) Date: Mon, 21 May 2012 12:40:10 +0200 Subject: [Gambas-devel] Gambas3 latest trunk xmlrpc broken Message-ID: Hi Ron, The error messages you saw (beginning with XMLDBG) are debug messages that I forgot ... I'll remove them. For the real error, I can't correct it without the code, but I have a little idea. The reader.node.attributes property (and a few others that I don't remember) returns Null if the current node isn't an element. So, you will need to check this, at least until I correct the problem. Regards, Adrien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ...572... Tue May 22 20:50:30 2012 From: ron at ...572... (Ron) Date: Tue, 22 May 2012 20:50:30 +0200 Subject: [Gambas-devel] Gambas3 latest trunk xmlrpc broken In-Reply-To: References: Message-ID: Adrian, ok thanks will try to look what it is, sometimes I can start my project and it will run, even with lots of xmlrpc calls. If i can find it I will try to create a small project for you to try ;-) Regards, Ron. 2012/5/21 Adrien Prokopowicz > Hi Ron, > The error messages you saw (beginning with XMLDBG) are debug messages that > I forgot ... > I'll remove them. > > For the real error, I can't correct it without the code, but I have a > little idea. > > The reader.node.attributes property (and a few others that I don't > remember) returns Null if the current node isn't an element. So, you will > need to check this, at least until I correct the problem. > > Regards, > Adrien. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gambas at ...1... Fri May 25 02:34:06 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Fri, 25 May 2012 02:34:06 +0200 Subject: [Gambas-devel] Compilation of gb.jit Message-ID: <4FBED37E.5020006@...1...> Hi, Let's talk on the developer mailing-list. It's better for archiving! Naively, I wanted to compile gb.jit by using the compilation flags returned by llvm-config. Result: the llvm headers cannot be compiled with them. Funny... :-/ So you were right in not taking them into account... -- Beno?t Minisini From lordheavym at ...176... Fri May 25 18:03:25 2012 From: lordheavym at ...176... (Laurent Carlier) Date: Fri, 25 May 2012 18:03:25 +0200 Subject: [Gambas-devel] Compilation of gb.jit In-Reply-To: <4FBED37E.5020006@...1...> References: <4FBED37E.5020006@...1...> Message-ID: 2012/5/25 Beno?t Minisini > Hi, > > Let's talk on the developer mailing-list. It's better for archiving! > > Naively, I wanted to compile gb.jit by using the compilation flags > returned by llvm-config. > > Result: the llvm headers cannot be compiled with them. Funny... :-/ > > So you were right in not taking them into account... > > -- > Beno?t Minisini > > Now gb.jit use the AC_PROG_PATH() macro, so LLVM_CONFIG environment variable can be use to force the path of the llvm-config file or in case of a different name (versioned name in case of debian). ex: LLVM_CONFIG=/usr/bin/llvm-config-3.2 ./configure ++ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Fri May 25 20:16:34 2012 From: tobias at ...692... (tobi) Date: Fri, 25 May 2012 20:16:34 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() Message-ID: <20120525181634.GA1483@...693...> Hi, I've been having trouble for some hours now. I seem to have managed to isolate the problem to a misunderstanding of GB.CanRaise(), on my side. There is a test project: [.src/MMain.module] --8<--------------- ' Gambas module file Public Sub Main() Object.Attach(Window, Me, "Window") Window.SetFocus() End Public Sub Window_Read() Dim iKey As Integer = Window.Read() Window.Print(Str$(iKey) & "\n\r") Window.Print("===") Window.Locate(0, IIf(Window.CursorY = Window.Height - 1, 0, -1)) If iKey = Key["q"] Then Quit End --8<--------------- and I simply can't manage to get that Window_Read() event risen. By using Object.Attach() above, I should be able to catch events from the Window. When I do Window.SetFocus() some internal stuff happens which produces desired results. During component initialisation, I begin watching the input queue of the program. If I press a key, I get into the GB_WATCH_READ callback and begin debugging: (gdb) break INPUT_callback (gdb) r [...] -> Keypress Breakpoint 1, INPUT_callback (fd=0, flag=1, arg=0) at input.c:108 (gdb) list [...] 109 WINDOW_raise_read(NULL); [...] (gdb) break WINDOW_raise_read (gdb) c Continuing. Breakpoint 2, WINDOW_raise_read (_object=0x0) at c_window.c:639 (gdb) list 640 if (!_object) 641 _object = focused; 642 643 if (_object && GB.CanRaise(GB.Parent(_object), EVENT_Read)) 644 GB.Raise(_object, EVENT_Read, 0); [...] (gdb) break 643 Breakpoint 3 at 0xb76e8537: file c_window.c, line 643. (gdb) c Continuing. Breakpoint 3, WINDOW_raise_read (_object=0x9ca1c84) at c_window.c:643 643 if (_object && GB.CanRaise(GB.Parent(_object), EVENT_Read)) (gdb) You see that _object is non-NULL. It seems, consequently, that GB.CanRaise() returns false. I looked up the macro OBJECT_has_events() used there: (((OBJECT *)_object)->class->n_event != 0) Then (gdb) break GB_CanRaise (gdb) c Breakpoint 4, GB_CanRaise (object=0x8e15aac, event_id=1) at gbx_api.c:467 warning: Source file is more recent than executable. (I think, I haven't compiled gbx3 yet since gb.jit...). However: (gdb) print ((OBJECT *) object)->class->n_event $1 = 0 There seems to lie the root of the whole problem... Sorry for being so verbose but I don't know what kind of information might help. What I expect is that I can intercept events from that module if I attach an event-rising object to it. What have I gotten wrong? Regards, Tobi From gambas at ...1... Fri May 25 20:26:03 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Fri, 25 May 2012 20:26:03 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() In-Reply-To: <20120525181634.GA1483@...693...> References: <20120525181634.GA1483@...693...> Message-ID: <4FBFCEBB.4090901@...1...> Le 25/05/2012 20:16, tobi a ?crit : > Hi, > > I've been having trouble for some hours now. I seem to have managed to isolate the problem to a > misunderstanding of GB.CanRaise(), on my side. > There is a test project: > > [.src/MMain.module] > --8<--------------- > ' Gambas module file > > Public Sub Main() > Object.Attach(Window, Me, "Window") > Window.SetFocus() > End > > Public Sub Window_Read() > Dim iKey As Integer = Window.Read() > > Window.Print(Str$(iKey)& "\n\r") > Window.Print("===") > Window.Locate(0, IIf(Window.CursorY = Window.Height - 1, 0, -1)) > If iKey = Key["q"] Then Quit > End > --8<--------------- > > and I simply can't manage to get that Window_Read() event risen. > By using Object.Attach() above, I should be able to catch events from the Window. When I do > Window.SetFocus() some internal stuff happens which produces desired results. During component > initialisation, I begin watching the input queue of the program. If I press a key, I get into the > GB_WATCH_READ callback and begin debugging: > > (gdb) break INPUT_callback > (gdb) r > [...] -> Keypress > > Breakpoint 1, INPUT_callback (fd=0, flag=1, arg=0) at input.c:108 > (gdb) list > [...] > 109 WINDOW_raise_read(NULL); > [...] > > (gdb) break WINDOW_raise_read > (gdb) c > Continuing. > > Breakpoint 2, WINDOW_raise_read (_object=0x0) at c_window.c:639 > (gdb) list > 640 if (!_object) > 641 _object = focused; > 642 > 643 if (_object&& GB.CanRaise(GB.Parent(_object), EVENT_Read)) > 644 GB.Raise(_object, EVENT_Read, 0); > [...] > (gdb) break 643 > Breakpoint 3 at 0xb76e8537: file c_window.c, line 643. > (gdb) c > Continuing. > > Breakpoint 3, WINDOW_raise_read (_object=0x9ca1c84) at c_window.c:643 > 643 if (_object&& GB.CanRaise(GB.Parent(_object), EVENT_Read)) > (gdb) > > You see that _object is non-NULL. It seems, consequently, that GB.CanRaise() returns false. I looked > up the macro OBJECT_has_events() used there: > > (((OBJECT *)_object)->class->n_event != 0) > > Then > > (gdb) break GB_CanRaise > (gdb) c > Breakpoint 4, GB_CanRaise (object=0x8e15aac, event_id=1) at gbx_api.c:467 > warning: Source file is more recent than executable. > > (I think, I haven't compiled gbx3 yet since gb.jit...). However: > > (gdb) print ((OBJECT *) object)->class->n_event > $1 = 0 > > There seems to lie the root of the whole problem... Sorry for being so verbose but I don't know what > kind of information might help. > What I expect is that I can intercept events from that module if I attach an event-rising object to > it. What have I gotten wrong? > > Regards, > Tobi > > The first argument of GB.CanRaise() is the object raising the event, not the object receiving the event. GB.CanRaise(A, B) means "If 'A' raises the event 'B', then there is an event handler that will catch it. In your case, it is useless, as the test is already done by GB.Raise(). GB.CanRaise() is useful only if you have an heavy computation to do before calling GB.Raise(). Regards, -- Beno?t Minisini From gambas at ...1... Fri May 25 20:45:05 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Fri, 25 May 2012 20:45:05 +0200 Subject: [Gambas-devel] Hooking the event loop In-Reply-To: <20120520202133.GF614@...693...> References: <20120520202133.GF614@...693...> Message-ID: <4FBFD331.9020308@...1...> Le 20/05/2012 22:21, tobi a ?crit : > Hi, > > I saw in gambas.h that I'm able to install a hook for the event loop. This simply is a function to > be called by the native event loop, as I saw in gb.qt4, right? Is there any policy to respect when I > install such a hook (like saving the former hook and calling it, too to not turn off any essential > attributes of other components)? > Of course, I wouldn't fiddle around with that without a reason: I have a module that will wait for a > key press and from then on continuously raise events until a key release occurs. I need a point > where it makes sense to install a function that periodically dispatches that event. You see, it is > handled by logic so I have no fd or something to GB.Watch()... > > Regards, > Tobi > Actually it's not a hook. It must be a full implementation of an event loop. The Gambas interpreter has an internal event loop. GUI tookits usually implement their own event loop, that is of course not compatible with the Gambas one. So, by specifying the 'LOOP' hook, you tell the interpreter not to use its own event loop, but let the toolkit use its own one. I don't give you all the detail. It is more complex than that, because the toolkit event loop must be modified so that it can handle Gambas timers and file descriptor watches. Regards, -- Beno?t Minisini From tobias at ...692... Fri May 25 20:48:00 2012 From: tobias at ...692... (tobi) Date: Fri, 25 May 2012 20:48:00 +0200 Subject: [Gambas-devel] Hooking the event loop In-Reply-To: <4FBFD331.9020308@...1...> References: <20120520202133.GF614@...693...> <4FBFD331.9020308@...1...> Message-ID: <20120525184800.GB1483@...693...> On Fri, 25 May 2012, Beno?t Minisini wrote: > Le 20/05/2012 22:21, tobi a ?crit : > > Hi, > > > > I saw in gambas.h that I'm able to install a hook for the event loop. This simply is a function to > > be called by the native event loop, as I saw in gb.qt4, right? Is there any policy to respect when I > > install such a hook (like saving the former hook and calling it, too to not turn off any essential > > attributes of other components)? > > Of course, I wouldn't fiddle around with that without a reason: I have a module that will wait for a > > key press and from then on continuously raise events until a key release occurs. I need a point > > where it makes sense to install a function that periodically dispatches that event. You see, it is > > handled by logic so I have no fd or something to GB.Watch()... > > > > Regards, > > Tobi > > > > Actually it's not a hook. It must be a full implementation of an event loop. > > The Gambas interpreter has an internal event loop. GUI tookits usually > implement their own event loop, that is of course not compatible with > the Gambas one. So, by specifying the 'LOOP' hook, you tell the > interpreter not to use its own event loop, but let the toolkit use its > own one. > > I don't give you all the detail. It is more complex than that, because > the toolkit event loop must be modified so that it can handle Gambas > timers and file descriptor watches. > > Regards, > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > That was what I presumed. I don't need that anymore as I have GB.Every() now. From adrien.prokopowicz at ...176... Fri May 25 20:56:51 2012 From: adrien.prokopowicz at ...176... (Adrien Prokopowicz) Date: Fri, 25 May 2012 20:56:51 +0200 Subject: [Gambas-devel] Array management Message-ID: <10454099.zC996fNzkx@...696...> Hi, I need to remove items from a gambas array, and to clear it. Is there a way to do it with the C interface ? I didn't found the matching function in gambas.h. Regards. From gambas at ...1... Fri May 25 21:15:12 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Fri, 25 May 2012 21:15:12 +0200 Subject: [Gambas-devel] Array management In-Reply-To: <10454099.zC996fNzkx@...696...> References: <10454099.zC996fNzkx@...696...> Message-ID: <4FBFDA40.4090500@...1...> Le 25/05/2012 20:56, Adrien Prokopowicz a ?crit : > Hi, > > I need to remove items from a gambas array, and to clear it. Is there a way to > do it with the C interface ? I didn't found the matching function in gambas.h. > > Regards. > Why do you need that? It's really needed? :-) -- Beno?t Minisini From tobias at ...692... Fri May 25 22:11:56 2012 From: tobias at ...692... (tobi) Date: Fri, 25 May 2012 22:11:56 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() In-Reply-To: <4FBFCEBB.4090901@...1...> References: <20120525181634.GA1483@...693...> <4FBFCEBB.4090901@...1...> Message-ID: <20120525201156.GC1483@...693...> On Fri, 25 May 2012, Beno?t Minisini wrote: > Le 25/05/2012 20:16, tobi a ?crit : > > Hi, > > > > I've been having trouble for some hours now. I seem to have managed to isolate the problem to a > > misunderstanding of GB.CanRaise(), on my side. > > There is a test project: > > > > [.src/MMain.module] > > --8<--------------- > > ' Gambas module file > > > > Public Sub Main() > > Object.Attach(Window, Me, "Window") > > Window.SetFocus() > > End > > > > Public Sub Window_Read() > > Dim iKey As Integer = Window.Read() > > > > Window.Print(Str$(iKey)& "\n\r") > > Window.Print("===") > > Window.Locate(0, IIf(Window.CursorY = Window.Height - 1, 0, -1)) > > If iKey = Key["q"] Then Quit > > End > > --8<--------------- > > > > and I simply can't manage to get that Window_Read() event risen. > > By using Object.Attach() above, I should be able to catch events from the Window. When I do > > Window.SetFocus() some internal stuff happens which produces desired results. During component > > initialisation, I begin watching the input queue of the program. If I press a key, I get into the > > GB_WATCH_READ callback and begin debugging: > > > > (gdb) break INPUT_callback > > (gdb) r > > [...] -> Keypress > > > > Breakpoint 1, INPUT_callback (fd=0, flag=1, arg=0) at input.c:108 > > (gdb) list > > [...] > > 109 WINDOW_raise_read(NULL); > > [...] > > > > (gdb) break WINDOW_raise_read > > (gdb) c > > Continuing. > > > > Breakpoint 2, WINDOW_raise_read (_object=0x0) at c_window.c:639 > > (gdb) list > > 640 if (!_object) > > 641 _object = focused; > > 642 > > 643 if (_object&& GB.CanRaise(GB.Parent(_object), EVENT_Read)) > > 644 GB.Raise(_object, EVENT_Read, 0); > > [...] > > (gdb) break 643 > > Breakpoint 3 at 0xb76e8537: file c_window.c, line 643. > > (gdb) c > > Continuing. > > > > Breakpoint 3, WINDOW_raise_read (_object=0x9ca1c84) at c_window.c:643 > > 643 if (_object&& GB.CanRaise(GB.Parent(_object), EVENT_Read)) > > (gdb) > > > > You see that _object is non-NULL. It seems, consequently, that GB.CanRaise() returns false. I looked > > up the macro OBJECT_has_events() used there: > > > > (((OBJECT *)_object)->class->n_event != 0) > > > > Then > > > > (gdb) break GB_CanRaise > > (gdb) c > > Breakpoint 4, GB_CanRaise (object=0x8e15aac, event_id=1) at gbx_api.c:467 > > warning: Source file is more recent than executable. > > > > (I think, I haven't compiled gbx3 yet since gb.jit...). However: > > > > (gdb) print ((OBJECT *) object)->class->n_event > > $1 = 0 > > > > There seems to lie the root of the whole problem... Sorry for being so verbose but I don't know what > > kind of information might help. > > What I expect is that I can intercept events from that module if I attach an event-rising object to > > it. What have I gotten wrong? > > > > Regards, > > Tobi > > > > > > The first argument of GB.CanRaise() is the object raising the event, not > the object receiving the event. > > GB.CanRaise(A, B) means "If 'A' raises the event 'B', then there is an > event handler that will catch it. > > In your case, it is useless, as the test is already done by GB.Raise(). > > GB.CanRaise() is useful only if you have an heavy computation to do > before calling GB.Raise(). > > Regards, > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > I found out that using what you mentioned above (that's what I first did, actually), I get an n_event of 1 which is right. For some reason - those, that I wanted to debug out but fear to die from starvation before again compile gbx, because compiling LLVM takes aeons in my machine - GB.CanRaise() still returns false. (I think I need it because I want to determine if the Window would raise an event and if not, the parent Screen object will raise it) Can you blindly think of any reasons for GB.CanRaise() returning false? Regards, Tobi From adrien.prokopowicz at ...176... Fri May 25 22:23:54 2012 From: adrien.prokopowicz at ...176... (Adrien Prokopowicz) Date: Fri, 25 May 2012 13:23:54 -0700 (PDT) Subject: [Gambas-devel] Array management In-Reply-To: <4FBFDA40.4090500@...1...> References: <10454099.zC996fNzkx@...696...> <4FBFDA40.4090500@...1...> Message-ID: <1390576.2VWeKpUUuC@...696...> Le vendredi 25 mai 2012 21:15:12 Beno?t Minisini a ?crit : > Le 25/05/2012 20:56, Adrien Prokopowicz a ?crit : > > Hi, > > > > I need to remove items from a gambas array, and to clear it. Is there a > > way to do it with the C interface ? I didn't found the matching function > > in gambas.h. > > > > Regards. > > Why do you need that? It's really needed? :-) Oh well, i just think about something, so it is not needed, you're right. :-) I wanted to store the nodes that XmlReader has just read (from Socket, File ...) into a gambas array, because it is faster to return. But I just think that the array must be read-only ... so I need to make a copy anyway (and I know how to clear a C array). ;-) From gambas at ...1... Fri May 25 22:59:31 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Fri, 25 May 2012 22:59:31 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() In-Reply-To: <20120525201156.GC1483@...693...> References: <20120525181634.GA1483@...693...> <4FBFCEBB.4090901@...1...> <20120525201156.GC1483@...693...> Message-ID: <4FBFF2B3.2030805@...1...> Le 25/05/2012 22:11, tobi a ?crit : > > I found out that using what you mentioned above (that's what I first did, actually), I get an > n_event of 1 which is right. For some reason - those, that I wanted to debug out but fear to > die from starvation before again compile gbx, because compiling LLVM takes aeons in my > machine - GB.CanRaise() still returns false. (I think I need it because I want to determine if > the Window would raise an event and if not, the parent Screen object will raise it) > Can you blindly think of any reasons for GB.CanRaise() returning false? > > Regards, > Tobi > If GB.CanRaise() returns FALSE, that means that raising the event will have no effect. Commit your code so that I can see how you use it! -- Beno?t Minisini From tobias at ...692... Fri May 25 23:08:36 2012 From: tobias at ...692... (tobi) Date: Fri, 25 May 2012 23:08:36 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() In-Reply-To: <4FBFF2B3.2030805@...1...> References: <20120525181634.GA1483@...693...> <4FBFCEBB.4090901@...1...> <20120525201156.GC1483@...693...> <4FBFF2B3.2030805@...1...> Message-ID: <20120525210836.GD1483@...693...> On Fri, 25 May 2012, Beno?t Minisini wrote: > Le 25/05/2012 22:11, tobi a ?crit : > > > > I found out that using what you mentioned above (that's what I first did, actually), I get an > > n_event of 1 which is right. For some reason - those, that I wanted to debug out but fear to > > die from starvation before again compile gbx, because compiling LLVM takes aeons in my > > machine - GB.CanRaise() still returns false. (I think I need it because I want to determine if > > the Window would raise an event and if not, the parent Screen object will raise it) > > Can you blindly think of any reasons for GB.CanRaise() returning false? > > > > Regards, > > Tobi > > > > If GB.CanRaise() returns FALSE, that means that raising the event will > have no effect. > > Commit your code so that I can see how you use it! > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > Here you are From sebikul at ...176... Sat May 26 05:47:33 2012 From: sebikul at ...176... (Sebastian Kulesz) Date: Sat, 26 May 2012 00:47:33 -0300 Subject: [Gambas-devel] Crash using gb.JIT Message-ID: Hi, I'm getting a crash when enabling JIT compilation on a class. The output, including debug messages, can be found on this paste: http://pastebin.com/FPM3eYqf Let me know if i can be of any help! Thanks! From sebikul at ...176... Sat May 26 05:53:06 2012 From: sebikul at ...176... (Sebastian Kulesz) Date: Sat, 26 May 2012 00:53:06 -0300 Subject: [Gambas-devel] Crash using gb.JIT In-Reply-To: References: Message-ID: Another crash here: gb.jit: using LLVM 3.1. Stored value type does not match pointer operand type! store i64 %1195, i32* %1193 i32Broken module found, compilation aborted! Stack dump: 0. Running pass 'Function Pass Manager' on module 'jit_mod'. 1. Running pass 'Module Verifier' on function '@func_0_Module_6' What could be the reasons for a program to crash due to a bug on gb.JIT? Is there specific code we should avoid to include on a JIT compiled class? On Sat, May 26, 2012 at 12:47 AM, Sebastian Kulesz wrote: > Hi, I'm getting a crash when enabling JIT compilation on a class. The > output, including debug messages, can be found on this paste: > http://pastebin.com/FPM3eYqf > > Let me know if i can be of any help! > > Thanks! From gambas at ...1... Sat May 26 12:47:52 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 26 May 2012 12:47:52 +0200 Subject: [Gambas-devel] Crash using gb.JIT In-Reply-To: References: Message-ID: <4FC0B4D8.8030906@...1...> Le 26/05/2012 05:53, Sebastian Kulesz a ?crit : > Another crash here: > > gb.jit: using LLVM 3.1. > Stored value type does not match pointer operand type! > store i64 %1195, i32* %1193 > i32Broken module found, compilation aborted! > Stack dump: > 0. Running pass 'Function Pass Manager' on module 'jit_mod'. > 1. Running pass 'Module Verifier' on function '@func_0_Module_6' > > What could be the reasons for a program to crash due to a bug on > gb.JIT? Is there specific code we should avoid to include on a JIT > compiled class? > > On Sat, May 26, 2012 at 12:47 AM, Sebastian Kulesz wrote: >> Hi, I'm getting a crash when enabling JIT compilation on a class. The >> output, including debug messages, can be found on this paste: >> http://pastebin.com/FPM3eYqf >> >> Let me know if i can be of any help! >> >> Thanks! > I think Emil will ask you the original code of the function! -- Beno?t Minisini From tobias at ...692... Sat May 26 14:41:09 2012 From: tobias at ...692... (tobi) Date: Sat, 26 May 2012 14:41:09 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() In-Reply-To: <20120525210836.GD1483@...693...> References: <20120525181634.GA1483@...693...> <4FBFCEBB.4090901@...1...> <20120525201156.GC1483@...693...> <4FBFF2B3.2030805@...1...> <20120525210836.GD1483@...693...> Message-ID: <20120526124109.GB623@...693...> On Fri, 25 May 2012, tobi wrote: > On Fri, 25 May 2012, Beno?t Minisini wrote: > > Le 25/05/2012 22:11, tobi a ?crit : > > > > > > I found out that using what you mentioned above (that's what I first did, actually), I get an > > > n_event of 1 which is right. For some reason - those, that I wanted to debug out but fear to > > > die from starvation before again compile gbx, because compiling LLVM takes aeons in my > > > machine - GB.CanRaise() still returns false. (I think I need it because I want to determine if > > > the Window would raise an event and if not, the parent Screen object will raise it) > > > Can you blindly think of any reasons for GB.CanRaise() returning false? > > > > > > Regards, > > > Tobi > > > > > > > If GB.CanRaise() returns FALSE, that means that raising the event will > > have no effect. > > > > Commit your code so that I can see how you use it! > > > > -- > > Beno?t Minisini > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Gambas-devel mailing list > > Gambas-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gambas-devel > > > > Here you are > Hum, I don't want to bother you again but I find my answer even less helpful now than yesterday. Let me explain the code a bit as I intend to tidy it up afterwards anyway. All input related stuff is worried about by the INPUT module input.c. It gets initialised by the main hook and then enters cbreak mode which I personally find the most useful for ncurses programs (signal generation from, e.g., ctrl-c and character-by-character input). Therefore, stdin becomes watched. A callback is associated to this watching, which is INPUT_callback(). This simply calls WINDOW_raise_read() (when entering NoDelay mode things get trickier internally but the event stuff will remain the same because, if even, only the watched fd changes). Then we are already at the problem with GB.CanRaise(). Don't stress yourself, I continue gb.ncurses on another frontier happily in the meantime. Regards, Tobi From gambas at ...1... Sat May 26 16:35:24 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 26 May 2012 16:35:24 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() In-Reply-To: <20120526124109.GB623@...693...> References: <20120525181634.GA1483@...693...> <4FBFCEBB.4090901@...1...> <20120525201156.GC1483@...693...> <4FBFF2B3.2030805@...1...> <20120525210836.GD1483@...693...> <20120526124109.GB623@...693...> Message-ID: <4FC0EA2C.7000206@...1...> Le 26/05/2012 14:41, tobi a ?crit : > > Hum, I don't want to bother you again but I find my answer even less helpful now than yesterday. Let > me explain the code a bit as I intend to tidy it up afterwards anyway. > > All input related stuff is worried about by the INPUT module input.c. It gets initialised by the > main hook and then enters cbreak mode which I personally find the most useful for ncurses programs > (signal generation from, e.g., ctrl-c and character-by-character input). Therefore, stdin becomes > watched. A callback is associated to this watching, which is INPUT_callback(). This simply calls > WINDOW_raise_read() (when entering NoDelay mode things get trickier internally but the event stuff > will remain the same because, if even, only the watched fd changes). Then we are already at the > problem with GB.CanRaise(). > > Don't stress yourself, I continue gb.ncurses on another frontier happily in the meantime. > > Regards, > Tobi > Do you have some Gambas project to let met check that? -- Beno?t Minisini From tobias at ...692... Sat May 26 17:37:57 2012 From: tobias at ...692... (tobi) Date: Sat, 26 May 2012 17:37:57 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() In-Reply-To: <4FC0EA2C.7000206@...1...> References: <20120525181634.GA1483@...693...> <4FBFCEBB.4090901@...1...> <20120525201156.GC1483@...693...> <4FBFF2B3.2030805@...1...> <20120525210836.GD1483@...693...> <20120526124109.GB623@...693...> <4FC0EA2C.7000206@...1...> Message-ID: <20120526153757.GA2114@...693...> On Sat, 26 May 2012, Beno?t Minisini wrote: > Le 26/05/2012 14:41, tobi a ?crit : > > > > Hum, I don't want to bother you again but I find my answer even less helpful now than yesterday. Let > > me explain the code a bit as I intend to tidy it up afterwards anyway. > > > > All input related stuff is worried about by the INPUT module input.c. It gets initialised by the > > main hook and then enters cbreak mode which I personally find the most useful for ncurses programs > > (signal generation from, e.g., ctrl-c and character-by-character input). Therefore, stdin becomes > > watched. A callback is associated to this watching, which is INPUT_callback(). This simply calls > > WINDOW_raise_read() (when entering NoDelay mode things get trickier internally but the event stuff > > will remain the same because, if even, only the watched fd changes). Then we are already at the > > problem with GB.CanRaise(). > > > > Don't stress yourself, I continue gb.ncurses on another frontier happily in the meantime. > > > > Regards, > > Tobi > > > > Do you have some Gambas project to let met check that? > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > Attached. You see that there are outputs to stderr at some points in the input.c and none of them are reached. The gambas code has, too, but neither that is reached. -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tar Type: application/x-tar Size: 20480 bytes Desc: not available URL: From tobias at ...692... Sun May 27 01:45:00 2012 From: tobias at ...692... (tobi) Date: Sun, 27 May 2012 01:45:00 +0200 Subject: [Gambas-devel] Question about GB.CanRaise() In-Reply-To: <20120526153757.GA2114@...693...> References: <20120525181634.GA1483@...693...> <4FBFCEBB.4090901@...1...> <20120525201156.GC1483@...693...> <4FBFF2B3.2030805@...1...> <20120525210836.GD1483@...693...> <20120526124109.GB623@...693...> <4FC0EA2C.7000206@...1...> <20120526153757.GA2114@...693...> Message-ID: <20120526234459.GE2114@...693...> On Sat, 26 May 2012, tobi wrote: > On Sat, 26 May 2012, Beno?t Minisini wrote: > > Le 26/05/2012 14:41, tobi a ?crit : > > > > > > Hum, I don't want to bother you again but I find my answer even less helpful now than yesterday. Let > > > me explain the code a bit as I intend to tidy it up afterwards anyway. > > > > > > All input related stuff is worried about by the INPUT module input.c. It gets initialised by the > > > main hook and then enters cbreak mode which I personally find the most useful for ncurses programs > > > (signal generation from, e.g., ctrl-c and character-by-character input). Therefore, stdin becomes > > > watched. A callback is associated to this watching, which is INPUT_callback(). This simply calls > > > WINDOW_raise_read() (when entering NoDelay mode things get trickier internally but the event stuff > > > will remain the same because, if even, only the watched fd changes). Then we are already at the > > > problem with GB.CanRaise(). > > > > > > Don't stress yourself, I continue gb.ncurses on another frontier happily in the meantime. > > > > > > Regards, > > > Tobi > > > > > > > Do you have some Gambas project to let met check that? > > > > -- > > Beno?t Minisini > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Gambas-devel mailing list > > Gambas-devel at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gambas-devel > > > > Attached. > You see that there are outputs to stderr at some points in the input.c and none of them are reached. > The gambas code has, too, but neither that is reached. > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel Beno?t, haha, I finally found it: c_window.c, WINDOW_setfocus(): GB.Ref((void **) &focused); is total nonsense. I have to give the pointer-pointer to Unref but not to Ref. With change to GB.Ref((void *) focused); it works perfectly. Regards, Tobi From gambas at ...1... Wed May 30 23:23:42 2012 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Wed, 30 May 2012 23:23:42 +0200 Subject: [Gambas-devel] Subversion commit log format Message-ID: <4FC68FDE.1000001@...1...> Hi Adrien, Beware with the subversion log format: you don't follow it, and all your commit logs will not be integrated to the global changelog automatically when Gambas 3.2 will be released. I will have to do that by hand. :-/ -- Beno?t Minisini