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

[Pharo-project] Pharo tips

by Javier PimÃ¡s

Hi, I was thinking that new users can get much help from did you know tips. But I don't like regular tips, which are shown in a modal window that just bothers the user. This are shown at the top of the window and should rotate automatically after some time. I developed the code in squeak4 because I had an image already open, and now when I open it in pharo I see that I have SystemWindowButton class missing. What steps should I follow to port that from Squeak? You can see a screenshot below, and are invited to write more tips, like keyboard shortcuts and anything you think is useful. By the way it is in http://www.squeaksource.com/PharoTips and you open it doing PharoTipsMorph show. Hope someone likes it, Javier. -- Javier PimÃ¡s Ciudad de Buenos Aires

May 14, 2010

Re: [Pharo-project] Keyboard Shortcuts in Pharo?

by Sean P. DeNigris

Lukas Renggli wrote: > >> SVI > > It is a hack on top of the Pluggable Morphic editor, that is a hack on > top of the Morphic editor, that is a hack on top of the MVC editor, > that is a hack on top of the original Smalltalk-80 editor. No joke. > Hey, I'm doing research on custom key bindings in Pharo. One of the key things (for me) is vim bindings. What makes SVI a hack, and if I was going to start from scratch, what approach would you recommend? Thanks. Sean -- View this message in context: http://forum.world.st/Keyboard-Shortcuts-in-Pharo-tp1298784p2216087.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2010

[Pharo-project] [NativeBoost] New update available

by Igor Stasenko

Hello all, i just published a heavily updated version of NativeBoost project. See http://code.google.com/p/nativeboost/wiki/Installation Also, a newer prebuilt win32 vm is available for download. Here the list of changes: VM side. - plugin no longer requires platform specific support code. All platform specific stuff is now [can be] implemented at language side. - added a small extension to Interpreter (#swapActiveContext:restoreMethod:) for callbacks support Language side. - NBUtils renamed to NativeBoost class and now will serve as a core API class, which is a starting place of most basic NativeBoost functionality - added a lazy and seamless image restart handling. None of NativeBoost code contributing to image startup phase. It starting up lazily and automatically, upon first access to its functionality. - added an external native function generator, to support generating a code and placing it into non-movable external memory region - various tests, bells & whistles. And last , but not least - added initial callback support There are two kinds of callbacks supported: native and language-side. With native callbacks , there is nothing fancy: generate native code and copy it to external memory. Then pass its address to any function which takes callback as argument. Period. A language-side callbacks required much more implementation effort to function properly, but easy to use by developers. You just need to subclass the NBFFICallback class, and override two methods at class side in your subclass: fnSpec & callType a #fnSpec should answer a callback function specification , like: #(int ( int a, int b)) and callType should answer either #cdecl or #stdcall, which tells what calling convention your function should use. To create a callback , just do: callback := MyCallback on: [:arg1 :arg2 | ... do something here .. ]. and then simply pass it to any FFI callout method which takes it as argument: self foo: x bar: y callback: callback where #foo:bar:callback: defined as FFI callout as followin: foo: aFoo bar: cylinder callback: fn <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout cdecl: #(void qsort (int aFoo, ulong cylinder, MyCallback fn)) module: 'myModule' note the name of class 'MyCallback' , supplied as argument type. This stuff is not tested throughoutly, so take care. I am used only a single function for testing callbacks - a qsort(), provided by C run-time library. The difference between natively-implemented callbacks and language-side ones is paramount (but that was expected, isnt? :) NBFFICallbackTests new benchQSort #(2689 184 21322) 2689 - array sort using purely smalltalk 184 - array sort with native callback 21322 - array sort with callback to a language side. Any comments and questions are wellcome. -- Best regards, Igor Stasenko AKA sig.

May 14, 2010

Re: [Pharo-project] keyboard shortcut for 'save image'

by Sean P. DeNigris

Preliminarily... Keymapping * adds names of shortcut groups, as symbols, in a morph's extension properties * changes Morph - extends with about 15 methods - overrides handleKeystroke: to invoke any key maps before normal handling process KeyBinder * registers as a keyboard listener with the ActiveHand I installed them both successfully in Squeak 4.1#10142 (figured Squeak would be closer to the image they were last known to work in). They seem to work with minor changes - tests and default shortcuts appear okay. I'd love to hear anyone's experience using either of these projects long-term... Cheers, Sean p.s. I'll check out SVI tomorrow - very interested in vi bindings. -- View this message in context: http://forum.world.st/keyboard-shortcut-for-save-image-tp1680084p2216065.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by Chris Muller

> installer) it seems. I am missing an implementation of a method > maAt:ifPresent:ifAbsent: on Smalltalk. Hi Mike, this is left-over from when Smalltalk became a SmalltalkImage. But I am confused because I thought I had those all cleaned up. Indeed, I did not find any senders of that to Smalltalk. Were you just trying to load it or run the test suite? If you would post the stack I would be able to see what you were trying to do and would be happy to fix it. - Chris > > anyone with a spare moment might like to figure that out. The > underscores need fixing in dependent packages (write barrier tests) > as well > > so we should maybe do something simpler to test the network. > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 14, 2010

Re: [Pharo-project] Problem in Pharo 1.1 (Igor?) : You have reached the size limit of the changes file.

by David T. Lewis

On Fri, May 14, 2010 at 02:33:38AM +0300, Igor Stasenko wrote: > 2010/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > > > On Thu, May 13, 2010 at 8:26 PM, St??phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> mariano > >> > >> i just released a fix could you stress the system? > > > > wiiiiiii > > > > My .changes is now 36MB. It seems to work ok. > > > Don't climb too high , failing would be painfull :) Actually you should keep climbing! The address mapping needs to do strange things on the 32MB boundaries for backward compatibility with the original 32MB address mapping. So keep loading those Seaside packages until you get to at least 150MB or so, just be to sure it keeps working over 32MB -> 64MB -> 96MB -> 128MB ... Dave

May 14, 2010

Re: [Pharo-project] Problem in Pharo 1.1 (Igor?) : You have reached the size limit of the changes file.

by Igor Stasenko

2010/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Thu, May 13, 2010 at 8:26 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> mariano >> >> i just released a fix could you stress the system? > > wiiiiiii > > My .changes is now 36MB. It seems to work ok. > Don't climb too high , failing would be painfull :) > >> >> Stef >> >> On May 13, 2010, at 2:31 PM, Mariano Martinez Peck wrote: >> >> > >> > >> > On Thu, May 13, 2010 at 1:17 PM, David T. Lewis <lewis(a)mail.msen.com> >> > wrote: >> > On Thu, May 13, 2010 at 10:56:17AM +0300, Igor Stasenko wrote: >> > > On 13 May 2010 10:33, St??phane Ducasse <stephane.ducasse(a)inria.fr> >> > > wrote: >> > > > oops >> > > > Igor do you have more information? >> > > > how do we do that? >> > > > >> > > just replace CompiledMethod>>checkOKToAdd:at:, or take it from trunk. >> > > >> > > As far as i can tell, everything else should work fine after that. >> > > This is not my contribution , so i don't know all nuances, sorry. >> > > >> > > I just made things which allow source pointers > 32Mb to be stored in >> > > method trailers, while others put this in use in various places :) >> > >> > That is probably all that is needed, yes. But be sure to test it. >> > When I did this for trunk, I tested by loading some big Monticello >> > package endlessly in a loop until I got the changes file up to >> > a couple hundred megabytes. You should be able to do this, save >> > and restart the image, browse all old methods is the sources file >> > and so forth. Then modify some method and make sure your change >> > appears at the end of the huge changes file, and that you can >> > revert your most recent change. And of course you should get no >> > warning dialog about the changes file size. >> > >> > Somebody with a fast computer should volunteer to test this. I >> > recall that it took a long time on my slow laptop computer with >> > slow disk drive ;) >> > >> > >> > >> > Thanks Dave. In my case, I accidently did something similar: I installed >> > Seaside 3.0 a couple of times: >> > >> > Gofer new >> > Â Â squeaksource: 'MetacelloRepository'; >> > Â Â package: 'ConfigurationOfSeaside'; >> > Â Â load. >> > >> > And then evaluate: >> > >> > ConfigurationOfSeaside project latestVersion load: #( 'Seaside 3.0' >> > 'Magritte2' 'Pier2' 'Pier2 AddOns' ). >> > >> > >> > There will be some errors and deprecated...just proceed them as this is >> > only to increase the .changes >> > >> > Cheers >> > >> > Mariano >> > >> > Dave >> > >> > >> > _______________________________________________ >> > 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 >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 13, 2010

Re: [Pharo-project] keyboard shortcut for 'save image'

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > This is why I would love that somebody > - look at the key binding > - look at the key binding implementation > - look at the old package supporting per editor key binding and puths > that to us > > Any taker? > I'm in the process of loading KeyBinder, KeyMapping, and SVI to see how they do what they do. I'm also collecting various feedback and information on those projects. When I paint a picture of what's been done, I'll present it here and on squeak-dev, so we can discuss the best way to proceed. I would be happy to write some code, but there is a good bit of changing core classes in at least one of the above packages, so I'd like to get a consensus before I dig in. Also, it seemed like annotations might be interesting, which none of the previous projects (that I saw) have used. Sean -- View this message in context: http://forum.world.st/keyboard-shortcut-for-save-image-tp1680084p2215943.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 13, 2010

Re: [Pharo-project] Pharo by example book: copying/pasting code snippets

by Mariano Martinez Peck

On Thu, May 13, 2010 at 11:35 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > > On 13 May 2010, at 23:19, StÃ©phane Ducasse wrote: > >> > >> On May 13, 2010, at 11:13 PM, Andrei Stebakov wrote: > >> > >>> When I copy and paste code snippets from the book, the compiler > complains about the minus signs (which is different character from what > Pharo expects): > >>> > >>> For example the line from the book: > >>> (j > 1) ifTrue: [ (cells at: i at: j - 1) toggleState]. > >>> I have to change to (with "short" minus sign) > >>> (j > 1) ifTrue: [ (cells at: i at: j - 1) toggleState]. > >>> Otherwise the method doesn't get accepted. > >>> I wonder if this is a PDF issue and if it could be corrected? > > > this is a pdf issue. > In my latex documents, using a lstlisting environment, this isn't a > problem... > Tested on OS X. > > Best regards > Stefan > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 13, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Igor Stasenko

2010/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Fri, May 14, 2010 at 12:15 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> On May 13, 2010, at 11:33 PM, Mariano Martinez Peck wrote: >> >> > Ok...now it seems to be working again. However, It takes MUCH more time >> > than in Pharo 1.0. >> >> can you be more precise? > > Yes, I can: > > "In PharoCore 10517" > MessageTally time: [Smalltalk condenseChanges]. -> 8127 > > "In PharoCore 11357" > MessageTally time: [Smalltalk condenseChanges]. 490523 > > >> >> Apparently they are a lot of methods hanging around and they should be >> cleaned. Now we do not care that condense >> Changes is fast or not. It works so perfect. >> > > Yes. But I am intrigued why. > array := ByteArray new: 100. Try compare speed between array at: 1 put: 10. and: arrayCopy := array copy. arrayCopy at: 1 put: 10. arrayCopy becomeForward: array. >> >> > I really don't care too much, I just want to know if this is expected or >> > not. >> > >> > Cheers >> > >> > Mariano >> > >> > On Tue, May 11, 2010 at 8:41 PM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > 2010/5/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> > > nicolas >> > > >> > > do you have an idea where we can look? >> > > >> > > Stef >> > > >> > >> > Sorry, I don't have time to dig into it... >> > But I think invent is a more appropriate verb than look in this case. >> > The ideas of Igor sound good to me, delegate some to CompiledMethods >> > and maybe use a mass becomeForward >> > >> > Nicolas >> > >> > > On May 10, 2010, at 6:26 PM, Nicolas Cellier wrote: >> > > >> > >> Sorry for the infinite loop, it was my fault. >> > >> I thought it had been detected and solved already (in squeak ?). >> > >> >> > >> Destroying source pointer of un-installed methods was just a >> > >> workaround to be used in case of already broken sources. >> > >> There is another strategy : detect the source pointer of un-installed >> > >> methods and store them in the new change log. >> > >> This has to be done before logging source code of installed methods. >> > >> >> > >> Nicolas >> > >> >> > >> 2010/5/9 Igor Stasenko <siguctua(a)gmail.com>: >> > >>> On 9 May 2010 23:17, Alain Plantec <alain.plantec(a)free.fr> wrote: >> > >>>> >> > >>>>> Ok, i took the 11343 >> > >>>>> - fixed the #condenseChanges >> > >>>>> - ran Â Smalltalk condenseChanges >> > >>>>> - changed the single method >> > >>>>> - saved image >> > >>>>> - ran Â Smalltalk condenseChanges again >> > >>>>> >> > >>>>> no crash reported. >> > >>>>> >> > >>>> >> > >>>> Indeed, with 11343 it seems ok. >> > >>>> With 11326 (updated -> 11346), crash during the second >> > >>>> condenseChanges :( >> > >>> >> > >>> Alain, could you please send me an image +.changes saved just before >> > >>> running a second condenseChanges? >> > >>> I'll try to find the cause of it. >> > >>> >> > >>>> Alain >> > >>>>> >> > >>>>> >> > >>>>>> >> > >>>>>> Alain >> > >>>>>> >> > >>>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> Pharo-project mailing list >> > >>>> Pharo-project(a)lists.gforge.inria.fr >> > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >>>> >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> Best regards, >> > >>> Igor Stasenko AKA sig. >> > >>> >> > >>> _______________________________________________ >> > >>> 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 >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> > _______________________________________________ >> > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 13, 2010