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

[Pharo-project] ss3 DNU (?)

by Clara Allende

Hi folks, when trying to open Tags section on ss3 page I get this: MessageNotUnderstood 2010: No method was found for the selector <#'>='> when sent to <aSSTag(children)> with arguments contained in <anArray( aSSTag(algorithm))>. Your request could not be completed. An exception occurred. The system administrator has been informed of this error. What does this mean? Cheers! -- "*Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.*" Linus Torvalds

May 7, 2012

Re: [Pharo-project] Instance variables references inside a method

by Carla Griggio

Thanks you!! El 07/05/2012, a las 15:27, Eliot Miranda <eliot.miranda(a)gmail.com> escribiÃ³: > Hi Carla, > > On Sun, May 6, 2012 at 2:12 AM, Carla F. Griggio <carla.griggio(a)gmail.com> wrote: > Yay! It works beautifully :D > > I added this method in CompiledMethod as an extension of my project: > > CompiledMethod>>referredInstVars > |theClass idx| > theClass := self methodClass. > ^theClass instVarNames select: [ :varName | > idx := theClass instVarIndexFor: varName. > (self readsField: idx) or: [ self writesField: idx ] > ] > > Here's an order N way, instead of an order N^2. > > referredInstVars > | allInstVarNames instVarNames | > allInstVarNames := self methodClass allInstVarNames. > self isReturnField ifTrue: > [^Set with: (allInstVarNames at: self returnField + 1)]. > instVarNames := Set new. > self abstractBytecodeMessagesDo: > [:msg| > (#(#popIntoReceiverVariable: > #pushReceiverVariable: > #storeIntoReceiverVariable:) includes: msg selector) ifTrue: > [instVarNames add: (allInstVarNames at: msg argument + 1)]]. > ^instVarNames > > "Dictionary newFromPairs: (Point selectors collect: [:s| { s. (Point >> s) referredInstVars}])" > > > > On Sun, May 6, 2012 at 6:04 AM, Carla F. Griggio <carla.griggio(a)gmail.com> wrote: > Thanks Guille! That gives me more tools to play with :P > > > On Sun, May 6, 2012 at 5:49 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > LÃder, > > you can do something like: > > class := myCompiledMethod methodClass. > class instVarNames select: [ :varName | > idx := class instVarIndexFor: varName. > myCompiledMethod readsField: idx or: [ myCompiledMethod writesField: idx ] > ] > > because #readsField: and #writesField: are index based. > > You can also see as an example: Behavior>>#whichSelectorsAccess: that is var named based, but over all class selectors. > > Guille > > > On Sun, May 6, 2012 at 10:38 AM, Carla F. Griggio <carla.griggio(a)gmail.com> wrote: > Hi! > I'm playing with some metaprogramming, and I'm stuck at trying to find out which instance variables are referred inside a method. > I've found that a CompiledMethod understands hasInstVarRefs, but I don't recognize a method that could tell just me what I'm looking for. > > Any leads? > > Thanks! > Carla. > > > > > > > -- > best, > Eliot > > <CompiledMethod-referredInstVars.st>

May 7, 2012

[Pharo-project] Running in background with OSProcess

by Sean P. DeNigris

How would I run '/usr/bin/java -jar "/path/to/jenkins.war" &' with OSProcess? Specifically I want to know the process number of the java child process. I unsuccessfully tried: * PipeableOSProcess command: '/usr/bin/java -jar "/path/to/jenkins.war" &', which successfully launches java, but I don't know its pid because the returned process is the completed parent "sh" that launched it * PipeableOSProcess command: '/usr/bin/java -jar "/path/to/jenkins.war"' (without ampersand), which also launches successfully, and leaves the parent "sh" process running as well (not as clean), but I still don't know the java pid I then succeeded with: p := PipeableOSProcess command: '/usr/bin/java -jar "/path/to/jenkins.war" & { echo $! ; }'. p output lines first. But this seems convoluted and I'm assuming there must be a simpler way. What is the best way to do this? I.e.: * launch a long running child process * without keeping the sh process open * accessing the pid of the child Thanks, Sean -- View this message in context: http://forum.world.st/Running-in-background-with-OSProcess-tp4615534.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 7, 2012

Re: [Pharo-project] Instance variables references inside a method

by Eliot Miranda

Hi Carla, On Sun, May 6, 2012 at 2:12 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > Yay! It works beautifully :D > > I added this method in CompiledMethod as an extension of my project: > > CompiledMethod>>referredInstVars > |theClass idx| > theClass := self methodClass. > ^theClass instVarNames select: [ :varName | > idx := theClass instVarIndexFor: varName. > (self readsField: idx) or: [ self writesField: idx ] > ] > Here's an order N way, instead of an order N^2. referredInstVars | allInstVarNames instVarNames | allInstVarNames := self methodClass allInstVarNames. self isReturnField ifTrue: [^Set with: (allInstVarNames at: self returnField + 1)]. instVarNames := Set new. self abstractBytecodeMessagesDo: [:msg| (#(#popIntoReceiverVariable: #pushReceiverVariable: #storeIntoReceiverVariable:) includes: msg selector) ifTrue: [instVarNames add: (allInstVarNames at: msg argument + 1)]]. ^instVarNames "Dictionary newFromPairs: (Point selectors collect: [:s| { s. (Point >> s) referredInstVars}])" > > On Sun, May 6, 2012 at 6:04 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > >> Thanks Guille! That gives me more tools to play with :P >> >> >> On Sun, May 6, 2012 at 5:49 AM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> LÃder, >>> >>> you can do something like: >>> >>> class := myCompiledMethod methodClass. >>> class instVarNames select: [ :varName | >>> idx := class instVarIndexFor: varName. >>> myCompiledMethod readsField: idx or: [ myCompiledMethod writesField: >>> idx ] >>> ] >>> >>> because #readsField: and #writesField: are index based. >>> >>> You can also see as an example: Behavior>>#whichSelectorsAccess: that >>> is var named based, but over all class selectors. >>> >>> Guille >>> >>> >>> On Sun, May 6, 2012 at 10:38 AM, Carla F. Griggio < >>> carla.griggio(a)gmail.com> wrote: >>> >>>> Hi! >>>> I'm playing with some metaprogramming, and I'm stuck at trying to find >>>> out *which* instance variables are referred inside a method. >>>> I've found that a CompiledMethod understands hasInstVarRefs, but I >>>> don't recognize a method that could tell just me what I'm looking for. >>>> >>>> Any leads? >>>> >>>> Thanks! >>>> Carla. >>>> >>> >>> >> > -- best, Eliot

May 7, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Eliot Miranda

On Sun, May 6, 2012 at 9:14 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2012/5/6 Igor Stasenko <siguctua(a)gmail.com>: > > On 6 May 2012 17:08, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > wrote: > >> 2012/5/6 Guillermo Polito <guillermopolito(a)gmail.com>: > >>> > >>> > >>> On Sun, May 6, 2012 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com > > > >>> wrote: > >>>> > >>>> <snip> > >>>> I'm more worried about having all-platforms-specific-stuff inside > image... > >>>> but we can mitigate that with fuel, and making loadable packages when > >>>> running the image... I don't know, I'm just thinking while writing, > so, this > >>>> is probably stupid :) > >>>> > >>> > >>> Just think how many times you took a development image and used it in > >>> several platforms. At least I don't. Same happened when I used > Eclipse. I > >>> didn't share my eclipses between systems. Even, I had several eclipse > >>> installations with their own plugins (just like images, hehe). > >>> > >>> Probably with jenkins, metacello, and kernel/bootstrap we can generate > >>> distributions per platform (With the possibility of an all-in-one > >>> distribution for the ones who like that). > >>> > >>> Guille > >> > >> Yes, I understand that we can live without this feature... > >> - If we can reconstruct images easily (one of the goal of Pharo) - I > >> mean not only code, but any object (eventually with Fuel) > >> - If we solve the bootstrap problem (or if we can still prepare an > >> image for cross platform startup) > >> - If we don't forget to always talk (send messages) thru an abstract > >> layer, and never directly name the target library, > >> > >> Since I didn't have all these tools in the past, I were forced to use > >> development images across different platform a lot, and yes, it was > >> not following the mainstream rules (a la "we can reconstruct all from > >> scratch") but damn powerful. > >> For deploying applications, it also is very powerful and cheap. > >> Personally, I would feel sore to lose it. > >> > > > > But look at the root of what we are talking about: N bytes in VM > > versus M bytes in image to support certain functionality. > > I think if you need it, you will make sure that those bytes is there > > and properly packaged with you application. > > > > Unfortunately, it's more than moving code... > What I mean is that when I need to pass an O_NONBLOCK flag to a FFI > call, it's going to be a problem because I have to know how this > information is encoded on each and every platform I want to support. > But there are solutions to this which mean you *don't* have to know. I wrote a prototype for VisualWorks that maps a SharedPool to these externally defined variables. Here's how it works. For each group of C constants, e.g. i/o constants, one populates a subclasss of SharedPoolForC with the variables one wants to define, and in a class-side method one defines the set of include files per platform that one should pull in to evaluate the constants. SharedPoolForC has code in it to automatically generate a C program, and compile it, e.g. to provide a shared library/dll for the current platform. The C program is essentially a name-value dictionary that maps from the abstract name #O_NONBLOCK to the size and value for a particular platform. SharedPoolForC also contains code to load the shared library/dll, extract the values and update the pool variables automatically. The deployment scheme is as follows, at start-up the system asks each SharedPoolForC subclass to check the platform and see if the platform has changed. If it hasn't changed, nothing needs to happen. If it has changed the system attempts to locate the shared library/dll for the current platform (the platform name is embedded in the dll's name), and update the pool variables from that dll, raising an exception if unavailable (and the exception could be mapped into a warning or an error to suit). So to deploy e.g. a one-click one needs to generate the set of dlls fort the platforms one wants to deploy on. The development scheme is simply to run a method on the SharedPoolForC when one adds some class variables and/or changes the set of include files which turns the crank, generating, compiling and loading the C file to get the value(s) for the new variable(s). An alternative scheme would generate a program that would print e.g. STON, which could be parsed or evaluated to compute the values. This would have the advantage that the definitions of the values are readable and editable by mere humans. So I think I'd discard the shared library/dll approach and keep it simple. At least, in C code, I just care about the symbolic information and > have a relatively portable sentence. > To me that's one of the highest hurdle with FFI, because this is the > kind of complexity I wish I never cared of. > That's just a flavour of #define/#ifdef hell. > It can be worse if you want to interface with IPC (which has lot's of > different flavours). > Same for functions defined by macros that just use machine specific > structure layout... We can no longer use these structures as opaque > handles. > > > You can ship your product and use it on multiple platforms with ease, > > granted that appropriate platform-specific code is loaded into your > > image. > > With distribution using VMs it's a bit different story: it is a > > barrier with high entry cost. Especially if you think about all those > > RPMs, which is controlled by third-party maintainers. It is not that > > easy to directly control it, and much much slower in case if you need > > to deal with some problems. > > > > I agree on the principle, I always prefer to develop in FFI than hack > the VM, I'm far far more efficient on the former. > Nonetheless, I don't think FFI can magically solve all our problems. > In certain ways it can make them worse. > > Nicolas > > >> Nicolas > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > -- best, Eliot

May 7, 2012

Re: [Pharo-project] users of thisContext

by Eliot Miranda

On Mon, May 7, 2012 at 1:27 AM, Francisco Garau <francisco.garau(a)gmail.com>wrote: > Hi -- I am trying to find the methods who make reference to the * > thisContext* pseudo variable. > > Any ideas how to get that list? > SystemNavigation new browseAllSelect: [:m| m scanFor: 137] 137 is the bytecode for pushThisContext. See BytecodeEncoder and subclasses. Or print e.g. thisContext method symbolic > > - Francisco > -- best, Eliot

May 7, 2012

[Pharo-project] [update 2.0] #20058

by Marcus Denker

20058 ----- Issue 5829: MessageSet can be removed http://code.google.com/p/pharo/issues/detail?id=5829 Issue 5828: New version of Nautilus http://code.google.com/p/pharo/issues/detail?id=5828 -- Marcus Denker -- http://marcusdenker.de

May 7, 2012

[Pharo-project] [update 2.0] #20057

by Marcus Denker

20057 ----- Issue 5824: Issue in list initialization if you do not use getList: but getListElement: instead http://code.google.com/p/pharo/issues/detail?id=5824 Issue 5825: New MessageBrowser http://code.google.com/p/pharo/issues/detail?id=5825 Issue 4575: ProtocolBrowser should be deprecated http://code.google.com/p/pharo/issues/detail?id=4575 If you want to check: do a "sender of " + ... the resulting list is actually usable. -- Marcus Denker -- http://marcusdenker.de

May 7, 2012

Re: [Pharo-project] FlatMessageListBrowser and class comments

by Guillermo Polito

On Mon, May 7, 2012 at 3:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Mariano > > the problem is that you need a widget to show the contents of changeset > and it contains class comment, class definition, methodsâ¦. > But somehow that widget should show those elements in different ways :). > > STef > > > > > Hi guys. I don't like the fact that FlatMessageListBrowser is being used > for more things than "messages". As an example, if you select a piece of > text, right click -> method source with it, it uses this class. However, > the resulted items are not all methods, but also class comments. What does > it mean: > > > > 1) I needed to implement #category in RGCommentDefinition (see > http://code.google.com/p/pharo/issues/detail?id=5821) > > 2) If you select a class comment, and then click the button senders, > implementors or version, it breaks (because they do not make sense for > class comments) > > 3) The class comment is displayed with shout, which is ugly and doesn't > make sense > > 4) etc... > > > > So I guess in the future we should have an abstract class say > FlatListBrowser with different concrete subclasses. The buttons, and the > code pane should be adopted to what is being show (the results). > > > > I know this would take time, but I just wanted to express my opinion. > > > > Cheers > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

May 7, 2012

Re: [Pharo-project] FlatMessageListBrowser and class comments

by StÃ©phane Ducasse

Mariano the problem is that you need a widget to show the contents of changeset and it contains class comment, class definition, methodsâ¦. STef > Hi guys. I don't like the fact that FlatMessageListBrowser is being used for more things than "messages". As an example, if you select a piece of text, right click -> method source with it, it uses this class. However, the resulted items are not all methods, but also class comments. What does it mean: > > 1) I needed to implement #category in RGCommentDefinition (see http://code.google.com/p/pharo/issues/detail?id=5821) > 2) If you select a class comment, and then click the button senders, implementors or version, it breaks (because they do not make sense for class comments) > 3) The class comment is displayed with shout, which is ugly and doesn't make sense > 4) etc... > > So I guess in the future we should have an abstract class say FlatListBrowser with different concrete subclasses. The buttons, and the code pane should be adopted to what is being show (the results). > > I know this would take time, but I just wanted to express my opinion. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com >

May 7, 2012