October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Odd deprecation message in UIManager

by Igor Stasenko

On 9 October 2011 08:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > At some point we should have a UI builder with specs like in vw. > I should do a little proto to show how it can work and that people understand the value and help but I want to finish rpackage and bootstrap first with specs? then it will be same as toolbuilder, no? my point is that the role of uimanager is to provide protocol(s) for basic stuff, and dont make it too wide. As for ui builder , i think it would be nice to have real ui editor which can serialize UI either into source code, or since we have fuel, we can serialize it into a bunch of bytes and then store them either in file or in image. > Stef > > >>> Hi! >>> >>> There is this method: >>> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> UIManager>>multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight >>> Â Â Â Â "Create a multi-line instance of me whose question is queryString with >>> Â Â Â Â the given initial answer. Invoke it centered at the given point, and >>> Â Â Â Â answer the string the user accepts. Â Answer nil if the user cancels. Â An >>> Â Â Â Â empty string returned means that the ussr cleared the editing area and >>> Â Â Â Â then hit 'accept'. Â Because multiple lines are invited, we ask that the user >>> Â Â Â Â use the ENTER key, or (in morphic anyway) hit the 'accept' button, to >>> Â Â Â Â submit; that way, the return key can be typed to move to the next line." >>> >>> Â Â Â Â self deprecated: 'Use multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: ' on: '7 September 2011' in: 'Pharo1.4'. >>> Â Â Â Â ^self subclassResponsibility >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> Apparently, the deprecation message says to use this very method. Which method should I use? Shall I open an entry? >>> >> i really wonder why such things are there? >> UI manager has to provide a simple interface, without any >> sophisticated stuff, like multiline/multibutton etc. >> Lets stop bloating the interface, it leads nowhere. >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > -- Best regards, Igor Stasenko.

Oct. 9, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Mariano Martinez Peck

On Sun, Oct 9, 2011 at 12:03 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Mariano > > > > No, that's impossible, and if posible, it is not worth it. Migrating from > an old format to a new one is extremelly complicated and innecessary. The > easiest way to solve this is to take the correct version of Fuel, > materialize the graph from the stream, load new version of Fuel, and > seriaize it again. That the easiest, more secure, and more practical > approach I can see. > > It would be interesting to see if you can get two different versions in > memory :) > heheh that would be nice :) > (a need for a module system) > yep, so far it is not possible. > so that you can load with one and save with the other. > > Stef > > > -- Mariano http://marianopeck.wordpress.com

Oct. 9, 2011

Re: [Pharo-project] Odd deprecation message in UIManager

by StÃ©phane Ducasse

At some point we should have a UI builder with specs like in vw. I should do a little proto to show how it can work and that people understand the value and help but I want to finish rpackage and bootstrap first Stef >> Hi! >> >> There is this method: >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> UIManager>>multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight >> "Create a multi-line instance of me whose question is queryString with >> the given initial answer. Invoke it centered at the given point, and >> answer the string the user accepts. Answer nil if the user cancels. An >> empty string returned means that the ussr cleared the editing area and >> then hit 'accept'. Because multiple lines are invited, we ask that the user >> use the ENTER key, or (in morphic anyway) hit the 'accept' button, to >> submit; that way, the return key can be typed to move to the next line." >> >> self deprecated: 'Use multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: ' on: '7 September 2011' in: 'Pharo1.4'. >> ^self subclassResponsibility >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> Apparently, the deprecation message says to use this very method. Which method should I use? Shall I open an entry? >> > i really wonder why such things are there? > UI manager has to provide a simple interface, without any > sophisticated stuff, like multiline/multibutton etc. > Lets stop bloating the interface, it leads nowhere. > > > > > -- > Best regards, > Igor Stasenko. >

Oct. 9, 2011

Re: [Pharo-project] Odd deprecation message in UIManager

by StÃ©phane Ducasse

check the same without the centerAt: because I removed all the callers that forces the user to place (responsibility of the manager not the user). and we should change the comments. On Oct 9, 2011, at 1:08 AM, Alexandre Bergel wrote: > Hi! > > There is this method: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > UIManager>>multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight > "Create a multi-line instance of me whose question is queryString with > the given initial answer. Invoke it centered at the given point, and > answer the string the user accepts. Answer nil if the user cancels. An > empty string returned means that the ussr cleared the editing area and > then hit 'accept'. Because multiple lines are invited, we ask that the user > use the ENTER key, or (in morphic anyway) hit the 'accept' button, to > submit; that way, the return key can be typed to move to the next line." > > self deprecated: 'Use multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: ' on: '7 September 2011' in: 'Pharo1.4'. > ^self subclassResponsibility > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Apparently, the deprecation message says to use this very method. Which method should I use? Shall I open an entry? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Oct. 9, 2011

Re: [Pharo-project] Odd deprecation message in UIManager

by Igor Stasenko

On 9 October 2011 02:08, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > There is this method: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > UIManager>>multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight > Â Â Â Â "Create a multi-line instance of me whose question is queryString with > Â Â Â Â the given initial answer. Invoke it centered at the given point, and > Â Â Â Â answer the string the user accepts. Â Answer nil if the user cancels. Â An > Â Â Â Â empty string returned means that the ussr cleared the editing area and > Â Â Â Â then hit 'accept'. Â Because multiple lines are invited, we ask that the user > Â Â Â Â use the ENTER key, or (in morphic anyway) hit the 'accept' button, to > Â Â Â Â submit; that way, the return key can be typed to move to the next line." > > Â Â Â Â self deprecated: 'Use multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: ' on: '7 September 2011' in: 'Pharo1.4'. > Â Â Â Â ^self subclassResponsibility > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Apparently, the deprecation message says to use this very method. Which method should I use? Shall I open an entry? > i really wonder why such things are there? UI manager has to provide a simple interface, without any sophisticated stuff, like multiline/multibutton etc. Lets stop bloating the interface, it leads nowhere. -- Best regards, Igor Stasenko.

Oct. 9, 2011

[Pharo-project] Odd deprecation message in UIManager

by Alexandre Bergel

Hi! There is this method: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= UIManager>>multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight "Create a multi-line instance of me whose question is queryString with the given initial answer. Invoke it centered at the given point, and answer the string the user accepts. Answer nil if the user cancels. An empty string returned means that the ussr cleared the editing area and then hit 'accept'. Because multiple lines are invited, we ask that the user use the ENTER key, or (in morphic anyway) hit the 'accept' button, to submit; that way, the return key can be typed to move to the next line." self deprecated: 'Use multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: ' on: '7 September 2011' in: 'Pharo1.4'. ^self subclassResponsibility -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Apparently, the deprecation message says to use this very method. Which method should I use? Shall I open an entry? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 8, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by StÃ©phane Ducasse

Mariano > No, that's impossible, and if posible, it is not worth it. Migrating from an old format to a new one is extremelly complicated and innecessary. The easiest way to solve this is to take the correct version of Fuel, materialize the graph from the stream, load new version of Fuel, and seriaize it again. That the easiest, more secure, and more practical approach I can see. It would be interesting to see if you can get two different versions in memory :) (a need for a module system) so that you can load with one and save with the other. Stef

Oct. 8, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Mariano Martinez Peck

s > > > > This is IMHO more than necessary for Fuel to become a production ready > > serializer and I'd say Fuel is now "old enough" to become such :) > > Yes. > Now what I would love is that even if fuel changes that the evolution of > information > is taken into account because like that it will be exercised for real. > > No, that's impossible, and if posible, it is not worth it. Migrating from an old format to a new one is extremelly complicated and innecessary. The easiest way to solve this is to take the correct version of Fuel, materialize the graph from the stream, load new version of Fuel, and seriaize it again. That the easiest, more secure, and more practical approach I can see. Cheers > > > > Best regards > > Janko > > > > > > > > -- > > Janko MivÅ¡ek > > Svetovalec za informatiko > > Eranova d.o.o. > > Ljubljana, Slovenija > > www.eranova.si > > tel: 01 514 22 55 > > faks: 01 514 22 56 > > gsm: 031 674 565 > > > > > -- Mariano http://marianopeck.wordpress.com

Oct. 8, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Mariano Martinez Peck

2011/10/8 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi guys, > > We are starting to use Fuel to exchange data daily, but without exactly > the same version of Fuel loaded, exported data is just too frequently > not importable anymore. Yes, that's true. We are changing its format all the time. > And exception report is meaningless, you can > only guess that Fuel version is to blame. > > Yes, thanks for reporting this. In fact, we have already fix it yesterday ;) Now, if you try to materialize with a different version, you will have a FLBadVersion exception. Check the tests FLVersionTest and FLSignatureTest for more details. > So, it is more that a time to: > > - stabilize and freeze the file format > We cannot. Let me just give you my thoughts: - It is a pity that we cannot make progress just because we break the format. If improving means breaking the format, we will do it. - The main question is WHY you need to update Fuel all the time? which are the reasons behind that? I have only 3 things in mind: a) because Fuel is too slow for you and hence you need a newer/faster version b) because you have changed Pharo version and Fuel doesn't work anymore there with the same version? c) because you found a bug. a) looks unlikely. I think Fuel was fast enough for most scenarios from the beginning even if new versions are faster. b) is unlikely also. For example, the last version (1.6) works out of the box in Pharo 1.2, 1.3 and 1.4. So it means that even between 3 versions of Pharo you don't need to update Fuel. c) we haven't found so far a critical bug which would requires to update Fuel. So...my question is, WHY you need to always use a new version of Fuel and why you cannot stay with a stable/fixed Metacello version? That's why we have metecello configurations. You can stick with version 1.6 (or whatever version) and just migrate when it is really necessary. For example, Francois Stephany is using Fuel for his website, and he is still using Fuel 1.4. He didn't need to update yet, because there aren't bugs and it is fast enough for what he needs. - put a version info into a file and check it while importing > Done. Thanks for the suggestion. > - meaningful error reporting in such cases > > Done also :) > This is IMHO more than necessary for Fuel to become a production ready > I totally agree. > serializer and I'd say Fuel is now "old enough" to become such :) > > heheheh yes. It is already more than year year old hhaa. BTW...yesterday we have finished with Martin the version 1.7 which we will release probably monday or tuesday. Cheers > Best regards > Janko > > > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > -- Mariano http://marianopeck.wordpress.com

Oct. 8, 2011

Re: [Pharo-project] Too many semaphores, image blocked

by Igor Stasenko

On 7 October 2011 23:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Oct 7, 2011 at 1:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> I don't understand why this problem appear only recently, and if i >> remember before i never heard that people >> had a problems with too many open sockets (and consequently exceeding >> a semaphore table space). >> >> Is there something we changed in language? in VM? or is it purely >> because we are lagging behind the scale of >> projects which today running on pharo? :) > > In the VM. Â In Cog I implemented a thread-safe non-blocking signal external > semaphore facility but I was too lazy to implement a thread-safe > non-blocking growing facility. Â It seems simple to set the size at start-up. > Â You choose a value large enough for your application, set it, save the > image and you're done. Â Whereas implementing a non-blocking growing facility > is tricky. >> Hmm, that confuses me even more. In Squeak VM there is a single hard limit for SemaphoresToSignalA, and SemaphoresToSignalB tables - 500 (i dont remember correct name of these tables). In these tables, upon receiving a signal, it storing the index of semaphore to signal, when you using signalSemaphore() function. Then at interrupt time, these tables are flushed by signaling corresponding semaphores which are stored in external semaphore table under corresponding index. This means that between two interrupts you cannot signal more than 500 semaphores. And given that time between interrupts are pretty small (about 1 ms) i hardly beleive that you can put such high load on server to receive more than 500 signals in 1 ms time period. So the problem is not here, apparently, the problem is in size of external semaphore table , where semaphore objects are stored, which growth can be controlled completely by image size (this is a simple array), because signaling machinery operating only with indexes in this table but not with actual semaphores. Now, since i don't know well how much changes you did in signaling code in Cog. I only suspect that your conclusion that your changes might cause the problems are wrong. > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

Oct. 8, 2011