August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-users] MethodName

by StÃ©phane Ducasse

> > > Hi Benjamin. Thanks a lot for all the work you are doing. When we start to build PharoDev 1.2 I would like to include your new recent submission and this method finder. I want to integrate recentMessage to replace the default one. Same for the new Finder once it is ready. I did not have the time. I think that this is important to take the time to rethink what we want. > It is very good idea to merge both, as it was very confusing. > > Here is my feedback > > 1) You have to provide a help text somewhere. Ok, entering a message name is easy. For example, if I want to see all messages like #setUp for example. That's intuitive. But, if I want to search the method that sending to an object 'aaa' answers me 'AAA', it is not intuitive to type: 'aaa' . 'AAA' . so....this should be explained somewhere. Maybe you can add a text explaining this (like it was in the previous tool) in the code panel. Because when you first open MethodName, the code panel is empy...you can use is and write there the text. Of course, an extra button help would be nice too :) > > 2) In addition to 1) writing a HelpSystem chapter / Pharo Collaborative book is important. What I mean is that if we are going to include a new tool in the Pharo mainstream, then it should be easy to use and documented. > > 3) The scroll of "change search envirorment" is veryyyyyyy slow. I know it is not "your" fault, but maybe someone can give you an idea of how to improve this. Maybe Tudor, Alexandre, Lukas, Gary...I don't know. > > 4) Most of the buttons are confusing because you don't know when you should be able to use them. For example, all the button (browse, senders, etc) are only usable when you select a specific implementor. But > > a) they are not disable at the beginning (before choosing a selector), thus someone would try to use them just after selecting a method name. > > b) not all of them require an implementor. For example, to search the senders, I don't need to select a particular implementor. Just having the selector is enough. > > So...I would put those buttons inside the right panel (where you list the implementors) or disable (grey) them when not needed. > > 5) This one is difficult to explain....Take method name and type in the serach inpit: 'aaa' . 'AAA'. Hit serach and you will see 'aaa' asUppercase -> 'AAA' listed in the left panel. If you click EVERYWHERE inside that panel, the first one is selected. Thus, it is easy and fast becasue you DONT need to go the the first raw and mark it. Ok? > > Now....do the same but write "setUp". You will see several methods that match that. Select any of them, and in the right panel you will have a list. A lot of times, there is one implementor. And of course you want that....but doing the same of the previous case doesn't work. You have to go exactly to that raw in order to select it. > > okok...I know, I am lazy :) > > Thanks again for this > > Mariano > > > > If you have advice or ideas, I'll thank you a lot ^^ > > > Benjamin > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] size vs basic and SizeMethodDictionary>>rehashWithoutBecome - Issue 1899

by StÃ©phane Ducasse

I really like this change because I would really like to have a kernel with as few as become: as possible. Thanks for answering the questions of guillermo and guillermo thanks for checking, asking and that we learn all. Stef > On Sat, 21 Aug 2010, Guillermo Polito wrote: > >> Hi! I wass looking at tha issue, specially at the item that says: >> >> "- ensure that #rehashWithoutBecome doesn't send #become:, making >> #rehashAllInstances a lot faster" >> >> And the change made in squeak was: >> >> Item was changed: >> ----- Method: MethodDictionary>>rehashWithoutBecome (in category >> 'private') ----- >> rehashWithoutBecome >> >> + | newInstance | >> + newInstance := self species new: self basicSize - 1. "Make >> sure it has the same capacity" >> + 1 to: self basicSize do: [ :index | >> + (self basicAt: index) ifNotNil: [ :key | >> + newInstance at: key put: (array at: index) ] ]. >> + ^newInstance! >> - | newSelf | >> - newSelf := self species new: self size. >> - 1 to: self basicSize do: [ :i | >> - | key | >> - (key := self basicAt: i) ifNotNil: [ >> - newSelf at: key put: (array at: i) ] ]. >> - ^newSelf! >> >> And I figured out that this change does nothing with its comment >> "ensure that #rehashWithoutBecome doesn't send #become:" >> >> Also, the only senders in the Core image are ScriptLoader >> SmalltalkImage (and there is no ?#rehashAllInstances ). >> >> ------------------------------------------ >> >> I tried this code before and after the change >> >> oldDicts := MethodDictionary allInstances. >> [ | newDicts | newDicts := Array new: oldDicts size. >> oldDicts withIndexDo: [ :d :index | newDicts at: index put: d >> rehashWithoutBecome ].] timeToRun >> >> And I saw a little improvement in performance (but it fluctuated a lot...). >> >> Does anyone know a performance difference between size and basicSize >> in Dictionary, HashedCollection or MethodDictionary? > > 1. #basicSize is only meaningful for MethodDictionary, for other HashedCollections it's not related to the elements of the collection (at least in Squeak). > 2. The performance difference (in Squeak) comes from the fact that if #size returns a power of two, then (with the old code) the MethodDictionary will grow when the last element is inserted by the loop. During the growth all elements will be hashed again and #become: will be used to swap the old and the new MethodDictionary, which is "very slow" in Squeak (and in Pharo). > > So if you apply the change and you have a few MethodDictionaries with power of two size in your image and all relevant changes from Squeak are applied, then you should see the speedup. > > All in all: in Squeak without this patch #rehashWithoutBecome could send #become: in the "background". > > > Levente > >> >> Thanks >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] FFI and underscores in 1.1 (RC2)

by StÃ©phane Ducasse

We will include it with a couple of 1.1.1 bug fixes. Stef On Aug 22, 2010, at 5:46 PM, Lukas Renggli wrote: > FYI: I fixed the #numArgs bug in > http://code.google.com/p/pharo/issues/detail?id=2844. > > Lukas > > On 22 August 2010 16:37, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Repeat after me: the Debugger is your friend. >> You just have to write something like >> >> Object compile: 'a_piInitialize: handle backend: backend host: host port: port >> "long odbx_init(odbx_t**, char*, char*, char*)" >> <cdecl: long ''odbx_init'' (ulong* char* char* char*) module: ''opendbx''> >> ^self externalCallFailed' >> >> in a workspace and select 'debug it' menu item. >> >> Since I'm in a good mood, I tell you the result: >> >> In Parser>>externalFunctionDeclaration you can see this sentence: >> >> (args position = self properties selector numArgs) ifFalse: [ >> ^self expected: 'Matching number of arguments']. >> >> What if you put an underscore in the selector ? >> >> #a_piInitialize:backend:host:port: numArgs -> -1 >> >> This means this selector is not recognized as a valid selector... >> So you have to fix String>>numArgs, then you'll be able to compile a >> selector with underscores. >> >> Repeat after me: the Debugger is your friend. >> >> Nicolas >> >> 2010/8/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> See 2842. >>> >>> Thanks for confirming it! >>> >>> Bill >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] >>> Sent: Sunday, August 22, 2010 5:41 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] FFI and underscores in 1.1 (RC2) >>> >>> I can reproduce the problem. I have this method that works: >>> >>> apiInitialize: handle backend: backend host: host port: port >>> "long odbx_init(odbx_t**, char*, char*, char*)" >>> <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >>> ^self externalCallFailed >>> >>> But not this one: >>> >>> apiInitialize: handle backend: backend host: host port: port >>> "long odbx_init(odbx_t**, char*, char*, char*)" >>> <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >>> ^self externalCallFailed >>> >>> a_piInitialize: handle backend: backend host: host port: port >>> "long odbx_init(odbx_t**, char*, char*, char*)" >>> <cdecl: long 'odbx_init' (ulong* char* char* char* Matching number of arguments expected ->) module: 'opendbx'> >>> ^self externalCallFailed >>> >>> >>> Please, open a ticket. Maybe Lukas can help us. >>> >>> Cheers >>> >>> Mariano >>> >>> >>> On Sat, Aug 21, 2010 at 9:47 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>> I just had an underwhelming response to my latest adventure into FFI, specifically wrapping the Acces IO USB API. Specifically, very few functions survived from description to actually being compiled. AFAICT, the compiler does not like underscores in method names for external functions. >>> >>> I'm not even sure how to describe it other than to give an example. This works: >>> >>> dIOWrite8:deviceIndex byteIndex:byteIndex data:data >>> "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long ByteIndex, unsigned char Data)" >>> >>> < cdecl: ulong 'DIO_Write8' ( ulong ulong byte ) > >>> ^self invalidCall. >>> >>> >>> This should compile, but it complains about a mismatch in the number of arguments: >>> >>> DIO_Write8:deviceIndex byteIndex:byteIndex data:data >>> "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long ByteIndex, unsigned char Data)" >>> >>> < cdecl: ulong 'DIO_Write8' ( ulong ulong byte ) > >>> ^self invalidCall. >>> >>> The less Pharo forces us to change names as given from the outside, the better off we will be. I am using a 1.1 RC2 image, just in case this has been fixed since then?? I really need to build a new image soon. >>> >>> Bill >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] FFI and underscores in 1.1 (RC2)

by StÃ©phane Ducasse

***thanks*** lukas! I love that spirit and atmosphere! This makes integrating far less boring. Stef On Aug 22, 2010, at 5:46 PM, Lukas Renggli wrote: > FYI: I fixed the #numArgs bug in > http://code.google.com/p/pharo/issues/detail?id=2844. > > Lukas > > On 22 August 2010 16:37, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Repeat after me: the Debugger is your friend. >> You just have to write something like >> >> Object compile: 'a_piInitialize: handle backend: backend host: host port: port >> "long odbx_init(odbx_t**, char*, char*, char*)" >> <cdecl: long ''odbx_init'' (ulong* char* char* char*) module: ''opendbx''> >> ^self externalCallFailed' >> >> in a workspace and select 'debug it' menu item. >> >> Since I'm in a good mood, I tell you the result: >> >> In Parser>>externalFunctionDeclaration you can see this sentence: >> >> (args position = self properties selector numArgs) ifFalse: [ >> ^self expected: 'Matching number of arguments']. >> >> What if you put an underscore in the selector ? >> >> #a_piInitialize:backend:host:port: numArgs -> -1 >> >> This means this selector is not recognized as a valid selector... >> So you have to fix String>>numArgs, then you'll be able to compile a >> selector with underscores. >> >> Repeat after me: the Debugger is your friend. >> >> Nicolas >> >> 2010/8/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> See 2842. >>> >>> Thanks for confirming it! >>> >>> Bill >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] >>> Sent: Sunday, August 22, 2010 5:41 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] FFI and underscores in 1.1 (RC2) >>> >>> I can reproduce the problem. I have this method that works: >>> >>> apiInitialize: handle backend: backend host: host port: port >>> "long odbx_init(odbx_t**, char*, char*, char*)" >>> <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >>> ^self externalCallFailed >>> >>> But not this one: >>> >>> apiInitialize: handle backend: backend host: host port: port >>> "long odbx_init(odbx_t**, char*, char*, char*)" >>> <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >>> ^self externalCallFailed >>> >>> a_piInitialize: handle backend: backend host: host port: port >>> "long odbx_init(odbx_t**, char*, char*, char*)" >>> <cdecl: long 'odbx_init' (ulong* char* char* char* Matching number of arguments expected ->) module: 'opendbx'> >>> ^self externalCallFailed >>> >>> >>> Please, open a ticket. Maybe Lukas can help us. >>> >>> Cheers >>> >>> Mariano >>> >>> >>> On Sat, Aug 21, 2010 at 9:47 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>> I just had an underwhelming response to my latest adventure into FFI, specifically wrapping the Acces IO USB API. Specifically, very few functions survived from description to actually being compiled. AFAICT, the compiler does not like underscores in method names for external functions. >>> >>> I'm not even sure how to describe it other than to give an example. This works: >>> >>> dIOWrite8:deviceIndex byteIndex:byteIndex data:data >>> "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long ByteIndex, unsigned char Data)" >>> >>> < cdecl: ulong 'DIO_Write8' ( ulong ulong byte ) > >>> ^self invalidCall. >>> >>> >>> This should compile, but it complains about a mismatch in the number of arguments: >>> >>> DIO_Write8:deviceIndex byteIndex:byteIndex data:data >>> "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long ByteIndex, unsigned char Data)" >>> >>> < cdecl: ulong 'DIO_Write8' ( ulong ulong byte ) > >>> ^self invalidCall. >>> >>> The less Pharo forces us to change names as given from the outside, the better off we will be. I am using a 1.1 RC2 image, just in case this has been fixed since then?? I really need to build a new image soon. >>> >>> Bill >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] FFI and underscores in 1.1 (RC2)

by StÃ©phane Ducasse

On Aug 22, 2010, at 4:37 PM, Nicolas Cellier wrote: > Repeat after me: the Debugger is your friend. > You just have to write something like the Debugger is your friend :D This is always one of the pattern that oscar identifies in Smalltalk programming. > > Object compile: 'a_piInitialize: handle backend: backend host: host port: port > "long odbx_init(odbx_t**, char*, char*, char*)" > <cdecl: long ''odbx_init'' (ulong* char* char* char*) module: ''opendbx''> > ^self externalCallFailed' > > in a workspace and select 'debug it' menu item. > > Since I'm in a good mood, I tell you the result: > > In Parser>>externalFunctionDeclaration you can see this sentence: > > (args position = self properties selector numArgs) ifFalse: [ > ^self expected: 'Matching number of arguments']. > > What if you put an underscore in the selector ? > > #a_piInitialize:backend:host:port: numArgs -> -1 > > This means this selector is not recognized as a valid selector... > So you have to fix String>>numArgs, then you'll be able to compile a > selector with underscores. > > Repeat after me: the Debugger is your friend. > > Nicolas > > 2010/8/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> See 2842. >> >> Thanks for confirming it! >> >> Bill >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] >> Sent: Sunday, August 22, 2010 5:41 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] FFI and underscores in 1.1 (RC2) >> >> I can reproduce the problem. I have this method that works: >> >> apiInitialize: handle backend: backend host: host port: port >> "long odbx_init(odbx_t**, char*, char*, char*)" >> <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >> ^self externalCallFailed >> >> But not this one: >> >> apiInitialize: handle backend: backend host: host port: port >> "long odbx_init(odbx_t**, char*, char*, char*)" >> <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >> ^self externalCallFailed >> >> a_piInitialize: handle backend: backend host: host port: port >> "long odbx_init(odbx_t**, char*, char*, char*)" >> <cdecl: long 'odbx_init' (ulong* char* char* char* Matching number of arguments expected ->) module: 'opendbx'> >> ^self externalCallFailed >> >> >> Please, open a ticket. Maybe Lukas can help us. >> >> Cheers >> >> Mariano >> >> >> On Sat, Aug 21, 2010 at 9:47 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >> I just had an underwhelming response to my latest adventure into FFI, specifically wrapping the Acces IO USB API. Specifically, very few functions survived from description to actually being compiled. AFAICT, the compiler does not like underscores in method names for external functions. >> >> I'm not even sure how to describe it other than to give an example. This works: >> >> dIOWrite8:deviceIndex byteIndex:byteIndex data:data >> "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long ByteIndex, unsigned char Data)" >> >> < cdecl: ulong 'DIO_Write8' ( ulong ulong byte ) > >> ^self invalidCall. >> >> >> This should compile, but it complains about a mismatch in the number of arguments: >> >> DIO_Write8:deviceIndex byteIndex:byteIndex data:data >> "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long ByteIndex, unsigned char Data)" >> >> < cdecl: ulong 'DIO_Write8' ( ulong ulong byte ) > >> ^self invalidCall. >> >> The less Pharo forces us to change names as given from the outside, the better off we will be. I am using a 1.1 RC2 image, just in case this has been fixed since then?? I really need to build a new image soon. >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] 'foo' asTime

by StÃ©phane Ducasse

The kind of think I hate. Time readFrom: aString I will deprecate it. I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague). Stef > Guess what it does. > > Not what I expect it to do. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] SocketStream enh

by StÃ©phane Ducasse

Thanks! I really think that we should systematically use a dependency management system. Of course it does not fix the problems but we can move on. I think that we can benefit of the idea of a platform classes hierarchy, this is why we push the change. >>>>>>> I will integrate the following SocketStream tests and before I would love to see if this >>>>>>> does not impact seaside >>>>>>> >>>>>>> http://code.google.com/p/pharo/issues/detail?id=2767 >>> >>> Does anybody have the time to give feedback on this important network changes? >> >> I did a short test with Seaside and everything still seems to work. And >> if it fixes bugs, I'm all tits forward about it. Ok I will integrate it now. This was the next item on the list. >> The deprecation of SmalltalkImage >> #platformName is a PITA though. It >> requires us to have different versions of Comanche and WebClient for >> different versions of Pharo. I will integrate now webClient. May be I will need to know what I should load in. :) > Pharo 1.0 is long outdated, Pharo 1.2 is not stable yet. We should > only target Pharo 1.1. > > Also the latest development tools only work in Pharo 1.1. There is no > point in making Seaside work in all versions. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] [Pharo-users] MethodName

by Mariano Martinez Peck

On Sun, Aug 22, 2010 at 3:09 AM, Benjamin Van Ryseghem < benjamin.vanryseghem(a)gmail.com> wrote: > Hello everybody, > > I'm working on a new project which consist in merging MethodFinder and > MessagesName. > > The first usable release can be loaded here : > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'MethodName'; > load. > > and it needs NullTextStyler > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'NullTextStyler'; > load. > > To open a Method Name browser, just clic World > Tools > Method Name or > MethodName new openInWorld. > Hi Benjamin. Thanks a lot for all the work you are doing. When we start to build PharoDev 1.2 I would like to include your new recent submission and this method finder. It is very good idea to merge both, as it was very confusing. Here is my feedback 1) You have to provide a help text somewhere. Ok, entering a message name is easy. For example, if I want to see all messages like #setUp for example. That's intuitive. But, if I want to search the method that sending to an object 'aaa' answers me 'AAA', it is not intuitive to type: 'aaa' . 'AAA' . so....this should be explained somewhere. Maybe you can add a text explaining this (like it was in the previous tool) in the code panel. Because when you first open MethodName, the code panel is empy...you can use is and write there the text. Of course, an extra button help would be nice too :) 2) In addition to 1) writing a HelpSystem chapter / Pharo Collaborative book is important. What I mean is that if we are going to include a new tool in the Pharo mainstream, then it should be easy to use and documented. 3) The scroll of "change search envirorment" is veryyyyyyy slow. I know it is not "your" fault, but maybe someone can give you an idea of how to improve this. Maybe Tudor, Alexandre, Lukas, Gary...I don't know. 4) Most of the buttons are confusing because you don't know when you should be able to use them. For example, all the button (browse, senders, etc) are only usable when you select a specific implementor. But a) they are not disable at the beginning (before choosing a selector), thus someone would try to use them just after selecting a method name. b) not all of them require an implementor. For example, to search the senders, I don't need to select a particular implementor. Just having the selector is enough. So...I would put those buttons inside the right panel (where you list the implementors) or disable (grey) them when not needed. 5) This one is difficult to explain....Take method name and type in the serach inpit: 'aaa' . 'AAA'. Hit serach and you will see 'aaa' asUppercase -> 'AAA' listed in the left panel. If you click EVERYWHERE inside that panel, the first one is selected. Thus, it is easy and fast becasue you DONT need to go the the first raw and mark it. Ok? Now....do the same but write "setUp". You will see several methods that match that. Select any of them, and in the right panel you will have a list. A lot of times, there is one implementor. And of course you want that....but doing the same of the previous case doesn't work. You have to go exactly to that raw in order to select it. okok...I know, I am lazy :) Thanks again for this Mariano > > If you have advice or ideas, I'll thank you a lot ^^ > > > Benjamin > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

Aug. 22, 2010

Re: [Pharo-project] Beyond animated gif?

by Schwab,Wilhelm K

Windows???? Oh, yeah, got it :) Actually, I think I have seen them play on Windows 7. Fortunately, I have no ready way to test that at the moment. Try looking here: http://www.munz.li/?p=48 Look at the over-copy in particular?? The image width might have to an even multiple of 4. Good luck, Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Chris Muller [asqueaker(a)gmail.com] Sent: Sunday, August 22, 2010 11:47 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Beyond animated gif? Hi Bill, I have this exact same requirement in one of my applications. I've started out using mencoder as well, but the "avi" videos files produced cannot be played in Windows. Are you able to play yours in Windows? 2010/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > mencoder can do the job. See > > http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-enc-images.html > > Don't work too hard on getting the list of files to work, at least be warned if you do. I put the resulting error message into Google and the first link was a patch with a question about where to send it. Helpful, if not encouraging. Listing the frame files on the command line does work; I am not sure when any limits on the length of the command line would strike. > > Note that I pass a collection of closures rather than forms; the hope is that it will be less resource hungry than creating all of the frames at one time. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K [bschwab(a)anest.ufl.edu] > Sent: Saturday, August 14, 2010 6:04 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Beyond animated gif? > > Hello all, > > I have a growing number of annotated images and thought it would be nice to make a movie out of them. Following the example of an animated gif, I had a result a LOT faster than I expected, but the quality is really poor. Maybe setting a palette would help, but I'm wondering if there are other/better ways? Extra credit goes to any solution that can be driven from within Pharo or at least w/o littering my drive with lots of images, but I'll take what I can get if the quality is right. > > images2mpg has been mentioned in a few places, but it is playing hard to get. > > Bill > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 22, 2010

Re: [Pharo-project] FFI and underscores in 1.1 (RC2)

by Nicolas Cellier

Great, thanks ! 2010/8/22 Lukas Renggli <renggli(a)gmail.com>: > FYI: I fixed the #numArgs bug in > http://code.google.com/p/pharo/issues/detail?id=2844. > > Lukas > > On 22 August 2010 16:37, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Repeat after me: the Debugger is your friend. >> You just have to write something like >> >> Object compile: 'a_piInitialize: handle backend: backend host: host port: port >> Â Â "long odbx_init(odbx_t**, char*, char*, char*)" >> Â Â <cdecl: long ''odbx_init'' (ulong* char* char* char*) module: ''opendbx''> >> Â Â ^self externalCallFailed' >> >> in a workspace and select 'debug it' menu item. >> >> Since I'm in a good mood, I tell you the result: >> >> In Parser>>externalFunctionDeclaration you can see this sentence: >> >> Â Â Â Â (args position = self properties selector numArgs) ifFalse: [ >> Â Â Â Â Â Â Â Â ^self expected: 'Matching number of arguments']. >> >> What if you put an underscore in the selector ? >> >> Â Â Â #a_piInitialize:backend:host:port: numArgs -> -1 >> >> This means this selector is not recognized as a valid selector... >> So you have to fix String>>numArgs, then you'll be able to compile a >> selector with underscores. >> >> Repeat after me: the Debugger is your friend. >> >> Nicolas >> >> 2010/8/22 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> See 2842. >>> >>> Thanks for confirming it! >>> >>> Bill >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] >>> Sent: Sunday, August 22, 2010 5:41 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] FFI and underscores in 1.1 (RC2) >>> >>> I can reproduce the problem. I have this method that works: >>> >>> apiInitialize: handle backend: backend host: host port: port >>> Â Â "long odbx_init(odbx_t**, char*, char*, char*)" >>> Â Â <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >>> Â Â ^self externalCallFailed >>> >>> But not this one: >>> >>> apiInitialize: handle backend: backend host: host port: port >>> Â Â "long odbx_init(odbx_t**, char*, char*, char*)" >>> Â Â <cdecl: long 'odbx_init' (ulong* char* char* char*) module: 'opendbx'> >>> Â Â ^self externalCallFailed >>> >>> a_piInitialize: handle backend: backend host: host port: port >>> Â Â "long odbx_init(odbx_t**, char*, char*, char*)" >>> Â Â <cdecl: long 'odbx_init' (ulong* char* char* char* Matching number of arguments expected ->) module: 'opendbx'> >>> Â Â ^self externalCallFailed >>> >>> >>> Please, open a ticket. Maybe Lukas can help us. >>> >>> Cheers >>> >>> Mariano >>> >>> >>> On Sat, Aug 21, 2010 at 9:47 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>> I just had an underwhelming response to my latest adventure into FFI, specifically wrapping the Acces IO USB API. Â Specifically, very few functions survived from description to actually being compiled. Â AFAICT, the compiler does not like underscores in method names for external functions. >>> >>> I'm not even sure how to describe it other than to give an example. Â This works: >>> >>> dIOWrite8:deviceIndex byteIndex:byteIndex data:data >>> Â Â Â "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long ByteIndex, unsigned char Data)" >>> >>> Â Â Â < cdecl: ulong 'DIO_Write8' ( Â ulong ulong byte ) > >>> Â Â Â ^self invalidCall. >>> >>> >>> This should compile, but it complains about a mismatch in the number of arguments: >>> >>> DIO_Write8:deviceIndex byteIndex:byteIndex data:data >>> Â Â Â "unsigned long DIO_Write8(unsigned long DeviceIndex, unsigned long ByteIndex, unsigned char Data)" >>> >>> Â Â Â < cdecl: ulong 'DIO_Write8' ( Â ulong ulong byte ) > >>> Â Â Â ^self invalidCall. >>> >>> The less Pharo forces us to change names as given from the outside, the better off we will be. Â I am using a 1.1 RC2 image, just in case this has been fixed since then?? Â I really need to build a new image soon. >>> >>> Bill >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 22, 2010