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

Re: [Pharo-project] How to copy some nice UI bits from Squeak4.1 (e.g. get rid of the fat buttons in OB)

by StÃ©phane Ducasse

Tim you can configure the MC browser to see the dirty in place or at the top. Bring the menu there is a radio button for that On Apr 27, 2010, at 12:11 AM, Tim Mackinnon wrote: > I loaded it into my 1.0 image (I have to confess it took me a moment to find the right package in monticello - the name "* OB-Standard" - the leading * putting it at the top meant that I couldn't find it at first - does that * mean that I changed a method in that package when I was putting self halt in methods?). > > Anyway - that does look much better! > > Is there a similar fix to make the window title bars smaller as well? On my mac they are larger than other native OSX windows, that is the browser title bars are bigger than the actual "Pharo 1.0 Image" title bar of the whole VM. I noticed that in Squeak 4.1 the title bars of all browsers all seem to be native size. I am wondering if there is a similar fix? > > Although - just having smaller buttons in that bar makes me feel more comfortable - and we'll see what the skeptics in the office say tomorrow! > > Tim > > > On 26 Apr 2010, at 10:20, Lukas Renggli wrote: > >>> I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports). >> >> I am using (and fixing) OB in Pharo 1.0. OB will only be adopted to >> the upcoming Pharo when Pharo 1.1 reaches a stable state so that I can >> confidently adopt it for my daily work. I don't have the time to >> maintain two OB branches. >> >> Though OB should work in Pharo 1.1 just fine, if you disable the >> deprecated warnings. >> >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 27, 2010

Re: [Pharo-project] [Moose-dev] Strange bug

by StÃ©phane Ducasse

We should check the Moose overrides? is there somewhere a method adding behavior to behavior and friends? I did not get the time to have a look. On Apr 26, 2010, at 11:29 PM, Tudor Girba wrote: > That is too low level for me :) > > Doru > > > On 26 Apr 2010, at 13:56, Cyrille Delaunay wrote: > >> Hello, >> >> Last week I had a error due to a strange behaviour: I had an instance variable and an accessor to this instance variable. The instance variable is instanciated at the initialization of the class. When the error occure, the instance variable is not nil (when inspecting it from the debugger ). But, when evaluating the accessor, it return nil. >> >> This occure in the pharo 1.0 dev image. I test it this morning on a clean image and on a click image with moose. It seems that the bug is specific to moose. If you want to reproduce it: >> >> Download the last version of Merlin from www.squeaksource.com/DelaunayTmpStuffs. >> run the method MerlinExamples class >> parametrizedMorphDropLists. it should work correctly. >> Now restart, load moose (load Conf

April 27, 2010

[Pharo-project] [Pharo-users] RB AST serialization

by Daniel Galdames

Hi, I'm working on a serialization of a RB AST, is in a very very earlier state, it can encode simple ASTs into a string but today i changed the encode methods, so now you can't decode the generated string :-P .Some node from AST-Core can't be encoded yet (RBPragmaNode, RBArrayNode, RBLiteralArrayNode) because I'm not sure what to encode, and the nodes aren't documented, at least in Pharo 1.0. Any comments and suggestions will be appreciated!! :-) I uploaded the code in squeaksource: http://www.squeaksource.com/AstSerializer.html I'm a bit new to Smalltalk and Pharo, so feel free to comment... Greetings, Daniel Galdames G.

April 27, 2010

Re: [Pharo-project] How to copy some nice UI bits from Squeak4.1 (e.g. get rid of the fat buttons in OB)

by Tim Mackinnon

I loaded it into my 1.0 image (I have to confess it took me a moment to find the right package in monticello - the name "* OB-Standard" - the leading * putting it at the top meant that I couldn't find it at first - does that * mean that I changed a method in that package when I was putting self halt in methods?). Anyway - that does look much better! Is there a similar fix to make the window title bars smaller as well? On my mac they are larger than other native OSX windows, that is the browser title bars are bigger than the actual "Pharo 1.0 Image" title bar of the whole VM. I noticed that in Squeak 4.1 the title bars of all browsers all seem to be native size. I am wondering if there is a similar fix? Although - just having smaller buttons in that bar makes me feel more comfortable - and we'll see what the skeptics in the office say tomorrow! Tim On 26 Apr 2010, at 10:20, Lukas Renggli wrote: >> I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports). > > I am using (and fixing) OB in Pharo 1.0. OB will only be adopted to > the upcoming Pharo when Pharo 1.1 reaches a stable state so that I can > confidently adopt it for my daily work. I don't have the time to > maintain two OB branches. > > Though OB should work in Pharo 1.1 just fine, if you disable the > deprecated warnings. > > 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

April 26, 2010

Re: [Pharo-project] [Moose-dev] Strange bug

by Tudor Girba

That is too low level for me :) Doru On 26 Apr 2010, at 13:56, Cyrille Delaunay wrote: > Hello, > > Last week I had a error due to a strange behaviour: I had an > instance variable and an accessor to this instance variable. The > instance variable is instanciated at the initialization of the > class. When the error occure, the instance variable is not nil (when > inspecting it from the debugger ). But, when evaluating the > accessor, it return nil. > > This occure in the pharo 1.0 dev image. I test it this morning on a > clean image and on a click image with moose. It seems that the bug > is specific to moose. If you want to reproduce it: > > Download the last version of Merlin from www.squeaksource.com/DelaunayTmpStuffs > . > run the method MerlinExamples class >> parametrizedMorphDropLists. > it should work correctly. > Now restart, load moose (load ConfigurationOfMoose, and evaluate > 'ConfigurationOfMoose loadDefault') and then load Merlin from > 'DelaunayTmpStuffs'. > It should raise an error and you should be able to see this strange > behaviour. From the debugger, evaluate 'self dropList' in > MorphDropListPart. > > After showing this bug to Marcus, it seems that something is not > weel compiled at one point: browse the method 'dropList' in > dropListPart. Now, click on 'view' and 'byte code'. The offset > indicated is 10 whereas it should be 15 > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Presenting is storytelling."

April 26, 2010

Re: [Pharo-project] making O/Ecompletion even better

by Romain Robbes

Thanks all for the feedback! Finding time is always hard, but I'll have a look at all your suggestions. Cheers, Romain On Apr 25, 2010, at 2:07 PM, Sean P. DeNigris wrote: > > I just dug up MacVim to double-check... > > I also always found not adding a space after completion to flow better than > having to delete the space at the end of the word, even if it may require a > few extra key strokes over the course of a line; because I don't have to do > a mental double hop to 'correct the correction' and my finger is right on > the spacebar anyway. > > Otherwise, I agree it works awesomely well :) > > Sean > -- > View this message in context: http://forum.world.st/making-O-Ecompletion-even-better-tp2064224p2064393.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://romain.robb.es rrobbes(a)dcc.uchile.cl

April 26, 2010

Re: [Pharo-project] [squeak-dev] World menu OCompletion-like algorithm

by Romain Robbes

A useful trick is that you can type in menus to select items. That's not the same, but still might help. Romain On Apr 25, 2010, at 4:41 PM, Sean P. DeNigris wrote: > > > Mariano Martinez Peck wrote: >> >> Open a couple of windows >> (browser, workspace, transcript, test runnerr, etc) and then, in the >> world, >> do a "shift + click" >> > > Cool feature, thanks. > > And, it seems that it shows a list of currently open windows, which is > different from 'the last three types of objects that I dealt with.' > > Use case (contrived): > I'm working in a sub-flow that requires me to constantly open a Transcript > window - say I'm manually testing (I know, disgusting, lol) code that closes > any open Transcript windows. So I want to reopen Transcript widnows via the > world menu over and over between tests. The 'all open windows menu' doesn't > help, but having Transcript pinned temporarily at the top of the world menu > would be very convenient. > > Btw of course I realize there are ways to do this (e.g. dragging the > Transcript menu item out of the menu onto the desktop), but having the top > three dynamically, automatically updated is what I'm toying with. > > - Sean > -- > View this message in context: http://forum.world.st/Re-squeak-dev-World-menu-OCompletion-like-algorithm-t… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://romain.robb.es rrobbes(a)dcc.uchile.cl

April 26, 2010

[Pharo-project] AlienOpenGL for demonstrating Alien

by Fernando olivero

If you have a Mac , you could download AlienOpenGL and play with it to understand how to model ( and call) external libraries in Smalltalk using Alien. Look at the following link, there you will find download and install instructions. http://www.squeaksource.com/AlienOpenGL.html. Cheers, Fernando On Apr 26, 2010, at 5:29 PM, Alwin Lin wrote: > Hi everyone! > > I'm a student learning to use smalltalk. I want to get the results from a C code program. I have searched a lot about this question on the internet, it seems i need to use a package called "alien" or something like FFI. But until now, I still don't have any concrete idea about how to do it. Could anyone please just tell me some examples about this question. Some simple source codes would be really appreciated. > > Thanks alot. > Sincerely > > Xin Lin > > > <ATT00001..txt>

April 26, 2010

[Pharo-project] (no subject)

by Alwin Lin

Hi everyone! I'm a student learning to use smalltalk. I want to get the results from a C code program. I have searched a lot about this question on the internet, it seems i need to use a package called "alien" or something like FFI. But until now, I still don't have any concrete idea about how to do it. Could anyone please just tell me some examples about this question. Some simple source codes would be really appreciated. Thanks alot. Sincerely Xin Lin

April 26, 2010

[Pharo-project] Strange bug

by Cyrille Delaunay

Hello, Last week I had a error due to a strange behaviour: I had an instance variable and an accessor to this instance variable. The instance variable is instanciated at the initialization of the class. When the error occure, the instance variable is not nil (when inspecting it from the debugger ). But, when evaluating the accessor, it return nil. This occure in the pharo 1.0 dev image. I test it this morning on a clean image and on a click image with moose. It seems that the bug is specific to moose. If you want to reproduce it: Download the last version of Merlin from www.squeaksource.com/DelaunayTmpStuffs. run the method MerlinExamples class >> parametrizedMorphDropLists. it should work correctly. Now restart, load moose (load ConfigurationOfMoose, and evaluate 'ConfigurationOfMoose loadDefault') and then load Merlin from 'DelaunayTmpStuffs'. It should raise an error and you should be able to see this strange behaviour. From the debugger, evaluate 'self dropList' in MorphDropListPart. After showing this bug to Marcus, it seems that something is not weel compiled at one point: browse the method 'dropList' in dropListPart. Now, click on 'view' and 'byte code'. The offset indicated is 10 whereas it should be 15

April 26, 2010