- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] [ANN] SimpleLogger released

by GermÃ¡n Arduino

2010/8/19 GÃ¶ran Krampe <goran(a)krampe.se>: > Hi all! > > I wonder a few things: > > - Why was SimpleLog deemed "hard"? The class comment on SLLog etc is pretty > straight forward IMHO! > - Also SimpleLog has some quite nice features: > Â Â Â Â - A really nice Morph to keep an eye on the logging going on, and to > easily filter it etc, although it needs some love for Pharo to compile. > Â Â Â Â - A log to file class with rotation. > Â Â Â Â - Ability to use syslog like Ramon posted, in fact, I think SimpleLog > was first with that. > > I just... wonder why we need to reinvent so many things over and over? > Is so bad to develop a small utility and put it open to the community? What thing is bad with this? > Toothpick IMHO was a bit complex, I agree - that was the reason for creating > SimpleLog, but hey, SimpleLog is *not* complex. > This is your opinion, I respect but don't agree. Anyway I think that this is a topic really not relevant, I shared a small class that I developed by the reason that can be useful to others, nothing more. > regards, GÃ¶ran > Cheers.

Aug. 22, 2010

[Pharo-project] [update 1.2] #12107

by StÃ©phane Ducasse

12107 ----- - Issue 2846: remove empty DeprecatedPreferences Package. - Issue 2838: should remove multilingual package. Stef

Aug. 22, 2010

Re: [Pharo-project] Working on Pharo 1.2

by Adrian Lienhard

Yes, this is possible (its done with a code part in Cmsbox that triggers the redirect, so updating is similar to editing some other content). But we should then regularly update the links so they don't get outdated. Is it worth? On Aug 20, 2010, at 09:06 , Marcus Denker wrote: > > On Aug 19, 2010, at 9:47 PM, Adrian Lienhard wrote: > >> Ok, here are the two URLs with redirects to the current 1.1 release downloads. >> >> http://pharo-project.org/pharo-download/stable >> http://pharo-project.org/pharo-download/stable-core >> > > can we have the same for unstable in a way that we can update to where the link > points to? > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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

[Pharo-project] [update 1.2] #12106

by StÃ©phane Ducasse

12106 ----- - Issue 2843: ColoredCodeStream not used. Thanks Marcus Denker. - Issue 2769: Fixes for broken SocketStream behavior. Thanks Andreas Raab Fix the loop in network tests. Stef

Aug. 22, 2010

[Pharo-project] [update 1.2] #12105

by StÃ©phane Ducasse

12105 ----- - Issue 2844: String>>#numArgs is broken - reformat String class>>#initialize so that the initializer gets executed (no other changes there) - fixed String>>#tokenish and String>>#numArgs - 4 new tests Thanks Lukas Renngli - Issue 2767: SocketStream>>upTo: and #upToAll: to fix an infinite loop. Thanks Andreas Raab. Apparently the fix does not solve the endless loop as in squeak. Stef

Aug. 22, 2010

Re: [Pharo-project] SocketStream enh

by StÃ©phane Ducasse

I will integrate another socket related fix because apparently the tests still break the image with these ones loaded. Stef On Aug 22, 2010, at 1:53 PM, Philippe Marschall wrote: > On 18.08.2010 12:56, StÃ©phane Ducasse wrote: >> >>>>>> 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. > > 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. > > 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] [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