June 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Having comments for pragma?

by Jan Vrany

> > In Java you *cannot* annotate any language element. You can annotate > class, methods, instance variables, method arguments and temporaries > and packages. > Then when I take an annotation, for example an hibernate annotation: > @Entity > @Table(name = "EMPLOYEE") > In the case of Hibernate, these annotation are for a class and they > are used at *runtime* to bind the class instances with database > entries (elements of this class are stored in the table EMPLOYEE). > > Now I've never seen anyone doing that, but as you can access the > annotation at runtime, and you can extract from the annotation its > name and its parameters (for example you could extract "Table" and > "name -> EMPLOYEE". Then, using the Java reflective features, you can > do something like: > > method = obj.getClass().getMethod(methodName, param1.class, > param2.class, ..); > method.invoke(obj, arg1, arg2,...); > And this way you execute a method named "Table", "name" or "EMPLOYEE" > with the parameter you want, as you could execute a method from any > string matching a method name. We have the same primitive in Pharo on > CompiledMethod. > > > I would not say that pragmas are more powerful in Java. Can you give > an example of something you can do with the Java annotation that you > can't do with Pharo pragmas ? Out of a curiosity, how can I annotate class, instance variable, method argument or temporary, or package. How can I annotate the pragma definition itself? How can I retrieve annotations of a pragma definition? I mean, I understand that you can *achieve* same effect, but you *can* achieve it as well with no pragma support at all. Jan > In Slang we use pragma to annotate argument and temporary variables > and it works just fine. When you describe in Pharo classes and > instance variables using Magritte you can do the same thing as just > annotating them. > > > >> Stef >> >

June 25, 2016

Re: [Pharo-dev] Having comments for pragma?

by ClÃ©ment Bera

On Sat, Jun 25, 2016 at 8:08 AM, stepharo <stepharo(a)free.fr> wrote: > > >> +1. I can't stress enough how useful it is to make pragmas real >> selectors with implementations and to try and apply them using >> perform:withArguments:. That's when their real power comes in. >> >> For example, if you have some method that wants to be added to some tool, >> make its pragma a message with all the information you need to add it as >> arguments (things like its position or priority relative to other >> additions, its name in the list of components, an icon to use, a string for >> fly-by help) and then implement a builder class whose methods match these >> pragmas so that when the builder performs the pragma it adds the method to >> the tool, in a given position, with a given icon and fly-by help etc. >> >> In most other systems method annotations are simply that, just passive >> labels. But in Smalltalk these are executable. You can browse for senders >> and implementors, you can execute them using a visitor pattern. Much more >> powerful. >> >> Hi eliot > > For the pragmas paper I read about annotation in Java and from what I > learned they are more powerful in Java. > They can annotate any language elements and they can also be executed (I > have to discuss with a Java expert to get it). > > In Java you *cannot* annotate any language element. You can annotate class, methods, instance variables, method arguments and temporaries and packages. Then when I take an annotation, for example an hibernate annotation: @Entity@Table(name = "EMPLOYEE") In the case of Hibernate, these annotation are for a class and they are used at *runtime* to bind the class instances with database entries (elements of this class are stored in the table EMPLOYEE). Now I've never seen anyone doing that, but as you can access the annotation at runtime, and you can extract from the annotation its name and its parameters (for example you could extract "Table" and "name -> EMPLOYEE". Then, using the Java reflective features, you can do something like: method = obj.getClass().getMethod(methodName, param1.class, param2.class, ..); method.invoke(obj, arg1, arg2,...); And this way you execute a method named "Table", "name" or "EMPLOYEE" with the parameter you want, as you could execute a method from any string matching a method name. We have the same primitive in Pharo on CompiledMethod. I would not say that pragmas are more powerful in Java. Can you give an example of something you can do with the Java annotation that you can't do with Pharo pragmas ? In Slang we use pragma to annotate argument and temporary variables and it works just fine. When you describe in Pharo classes and instance variables using Magritte you can do the same thing as just annotating them. Stef > >

June 25, 2016

Re: [Pharo-dev] Having comments for pragma?

by Tudor Girba

Hi, I believe we are missing a first class entity for a PragmaType. Essentially, I think that the class side of the Pragma class should become a full object. In fact, we already have a rudimentary version of this in Spotter because we needed an object to be able to browse all definitions of a certain pragma. So, now, I extended it with the concept of a user which is the list of all senders minus the methods that are annotated with a pragma. This helps distinguish the meaning of a pragma by looking at the code where it is being used. Perhaps we can find a better name than users. You can see these users in the inspector and in spotter: I think we should build on this. What do you think? Cheers, Doru > On Jun 24, 2016, at 3:54 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > A pragma may be very obscure. For example, I do: > Pragma allInstances anyOne > => <debuggerCompleteToSender> > > If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. > I see many methods having that pragma, but not idea what it is for. > I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method. > > What about having a way to comment pragma? Maybe something like > -=-=-=-=-=-= > Object subclass: #Pragma > instanceVariableNames: 'method keyword arguments comment' > -=-=-=-=-=-= > > And a simple way to annotate pragmas? > Just an idea. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

June 25, 2016

Re: [Pharo-dev] OS-Windows and UnifiedFFI

by stepharo

Example in chapter please :) Le 24/6/16 Ã 14:05, Esteban Lorenzano a Ã©crit : > >> On 24 Jun 2016, at 09:53, Nicolai Hess <nicolaihess(a)gmail.com >> <mailto:nicolaihess@gmail.com>> wrote: >> >> >> >> Iâm sorryâ¦ I do not understand. This is solved in UFFI since some >> months, and Torstenâs OSWindow uses it. >> >> >> Sorry then it is my fault. I know that Torsten already ported >> OSWindow to UFFI, and that most things are already working. >> >> UFFI provides FFIConstantHandle type to deal with windows HANDLE >> types, as comment says: >> >> I represent a constant HANDLE, as described in *Windows >> MSDN>https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457(v=vs.85).… >> <https://msdn.microsoft.com/en-us/library/windows/desktop/ms724457%28v=vs.85…> >> >> A ==HANDLE== is a special kind of external object who is accessed >> through numbers, therefore and ==ExternalAddress== is not >> appropriate to describe it (since they are constants and external >> addresses represents disposable spaces from memory). >> >> Is not clear this is necessary outside Windows, but according to >> documentation they are somekind analogous to unix's File >> Descriptors (but with some remarkable diferences, as documented >> *here>http://lackingrhoticity.blogspot.fr/2015/05/passing-fds-handles-between-pro…. >> >> Example: >> [[[ >> HWND := #FFIConstantHandle. >> self ffiCall: #(HWND GetActiveWindow()) >> ]]] >> >> >> is there anything Iâm missing? >> >> >> I don't know what else should I do, I already posted the example. >> The code I provided just don't work (DNU on isExternalAddress, see >> other mail), and I have no idea how to make it work. >> Yes, maybe I don't know enough about ffi for this type of the >> function argument passing. > > the example is a simplification, you cannot put both definition and > call in same methodâ¦ find attached a working example of what you want. > > > > > >> >> (actually I tried to port some NBOpenGL code to UFFI, for this I need >> to register a Window Class with WinWndClassEx (to create a gl context). >> So if this *is* already working, I need to look what I have done wrong). >> >> thanks for your response. >> nicolai >> >> >> Esteban >> >> >> >> >

June 25, 2016

Re: [Pharo-dev] Having comments for pragma?

by stepharo

> > +1. I can't stress enough how useful it is to make pragmas real > selectors with implementations and to try and apply them using > perform:withArguments:. That's when their real power comes in. > > For example, if you have some method that wants to be added to some > tool, make its pragma a message with all the information you need to > add it as arguments (things like its position or priority relative to > other additions, its name in the list of components, an icon to use, a > string for fly-by help) and then implement a builder class whose > methods match these pragmas so that when the builder performs the > pragma it adds the method to the tool, in a given position, with a > given icon and fly-by help etc. > > In most other systems method annotations are simply that, just passive > labels. But in Smalltalk these are executable. You can browse for > senders and implementors, you can execute them using a visitor > pattern. Much more powerful. > Hi eliot For the pragmas paper I read about annotation in Java and from what I learned they are more powerful in Java. They can annotate any language elements and they can also be executed (I have to discuss with a Java expert to get it). Stef

June 25, 2016

Re: [Pharo-dev] Reordering working directory mess

by Stephan Eggermont

On 24/06/16 18:14, Nicolas Passerini wrote: > I don't see why it couldn't be the default behavior. I think that it would > be a reasonable default, don't you? Not with our current Monticello/Metacello, it won't. You'll never be able to resolve configuration problems. Stephan

June 24, 2016

Re: [Pharo-dev] Having comments for pragma?

by Richard Sargent

Ben Coman wrote > On Fri, Jun 24, 2016 at 10:55 PM, ClÃ©ment Bera < > bera.clement@ > > > wrote: > >> Hi. >> >> Pragmas are selectors hence they're browsable. You can implement a method >> somewhere with the pragma selector name that includes the documentation. >> In >> VW they were careful about that and most, if not all, of their pragmas >> are >> carefully commented this way. >> >> > Should this be concentrated in a class like PragmaDocumentation, or spread > out (I don't know how). Since pragmas are an open set and can be added by any package, concentrating them in one place doesn't sound like a good idea. The best place to have the comments is with the code. If the pragmas name real selectors, comment the implementation. If the pragmas are merely tags, comment the method that declares them as pragmas (e.g. VisualWorks requires you to declare the symbols as pragmas before using them). Examples: SUnit.TestCase class>>#testMethodTags declares a couple of pragma selectors for instance methods. testMethodTags "Any method tagged with a <test> pragma is considered a test selector candidate" "<uses:> tags are used to compute instance specific resources for the tagged test. The argument is a symbol for the class name, or a binding reference to the same." <pragmas: #instance> ^#(#test #uses:) SUnit.TestCase class>>#testResourceTags declares a class method pragma for resources. testResourceTags "<resource:> tags are used to compute instance specific resources for the tagged test. The argument is a symbol for the class name, or a binding reference to the same." <pragmas: #class> ^#(#resource) ApplicationModel class>>menuMethodPragmas declares a whole slew of selectors for menus. But it neglects to provide comments in it or in the list of selectors in the Menu class. menuMethodPragmas <pragmas: #instance> <pragmas: #class> ^Menu pragmas However, VW does comment the actual methods: computedSubmenu: label nameKey: key menu: menuIDs position: position "This pragma expects the body of the method marked with it to answer a Menu that will be used as a submenu with the label and position specified by the pragma." > cheers -ben > > >> For example, if you have the pragma > <foo> > and you implement the method >> MyClass class >> #foo with some comments in it and you can double click >> on >> the pragma > <foo> > to select its content (foo) and press Cmd+M (or right >> click implementors) to get to the method having the documentation. >> > > > >> >> On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel < > alexandre.bergel@ > > > wrote: >> >>> Hi! >>> >>> A pragma may be very obscure. For example, I do: >>> Pragma allInstances anyOne >>> => > <debuggerCompleteToSender> >>> >>> If I want to know more about this > <debuggerCompleteToSender> > is actually >>> quite challenging. >>> I see many methods having that pragma, but not idea what it is for. >>> I see that Halt>>signalerContext and Process>>complete: that use that >>> pragma somehow. But still, I have no idea when I should use that pragma >>> in >>> my method. >>> >>> What about having a way to comment pragma? Maybe something like >>> -=-=-=-=-=-= >>> Object subclass: #Pragma >>> instanceVariableNames: 'method keyword arguments *comment*' >>> -=-=-=-=-=-= >>> >>> And a simple way to annotate pragmas? >>> Just an idea. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> -- View this message in context: http://forum.world.st/Having-comments-for-pragma-tp4902987p4903138.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 24, 2016

Re: [Pharo-dev] OS-Windows and UnifiedFFI

by Nicolai Hess

Yes! That is much better, thanks 2016-06-24 17:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 24 Jun 2016, at 16:43, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-24 16:03 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> if you send me the code, I can take a look. >> > > Sorry if this sounds rude, but > did you actually read my mail, I mean the first one. > > > wellâ¦ after search, it was from 25 aprâ¦ and my client didnât show it to me > (because I removed it, to clean)â¦ and it folded the quoted so yes, I read > itâ¦ like a month ago :) > > > If you don't have the time to look at this, it is ok. I will just try to > find it out myself, or maybe torsten has an idea. > > No problem. > > > well, but Iâm particularly interested in UFFI, since is my new toy :) > and seriously, I want to make him really solid, so I jump in whenever I > see a problem, even if Iâm doing something different (merging pharo-vm with > os-vm, now). > > Anyway, I see the error: WinWndClassEx is generated with bad mappingâ¦ this > is fixed in new versions of UFFI so you need to regenerate the fields: > > WinWndClassEx rebuildFieldAccessors. (Torsten needs to > > but thenâ¦ I spotted a bug, because FFIConstantHandle>>value is not defined > so you will still have an error :) > > anyway, I updated both, OSWindow and UFFI so if I you load bleedingEdge of > both, you will see something like this: > > > > I already posted the code multiple times. There is no code I could send. > It is all in the image (+ the OSWindow) project. > > I'll try it again. > > OS: Windows > - take a fresh > - load (from catalog browser) OSWindow > > - execute this > > | hInst wndClass | > hInst := WinProcess getVMModuleHandle. > wndClass := WinWndClassEx new. > wndClass hInstance: hInst. > > Error : > Unable to resolve external type: HMODULE > > OK, getVMModuleHandle expects a HMODULE type > We need to define a missing type, HMODULE, but that works (just like all > the other H-WinHandle-Types). > > Now execute it again: > New error: > "MessageNotUnderstood: SmallInteger>>isExternalAddress" > > The question is: > > Any Idea what is missing here, I need a way to store the HMODULE handle > in the structure of the WinWNdClassEx > >

June 24, 2016

Re: [Pharo-dev] Reordering working directory mess

by Paul DeBruicker

Can't this be accomplished today with a symbolic link to a package directory somewhere on your HD? e.g. rm -rf package-cache ln -s /path/to/my/common/package/repo package-cache Works for me at least. Nicolas Passerini wrote > I agree with Javier, it would be much nicer to have only one shared > package > cache and, while I understand that there might be people not wanting that, > I don't see why it couldn't be the default behavior. I think that it would > be a reasonable default, don't you? > > On Fri, Jun 24, 2016 at 3:54 PM, Javier PimÃ¡s < > elpochodelagente@ > > > wrote: > >> I don't know for the new directories, but I always thought that it would >> be nice to have package-cache in ~/.pharo or a place shared by all >> images, >> to avoid redownloading all .MCZs from other projects each time you launch >> pharo from a different directory. >> >> Cheers! >> Pocho >> >> On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano < > estebanlm@ > > >> wrote: >> >>> Hi, >>> >>> Since some time Iâve seen growing the amount of files/directories >>> generated when running Pharo. Up to Pharo 2.0, we had just this: >>> >>> Pharo.image >>> Pharo.changes >>> PharoDebug.log >>> pharo-cache >>> >>> now we have: >>> >>> Pharo.image >>> Pharo.changes >>> PharoDebug.log >>> pharo-cache >>> epicea-sessions >>> play-cache >>> play-stash >>> >>> it does not looks like much, but I think this does not looks >>> professional >>> (we take too much from user space). So I proposed (and implemented) a >>> âconcentratorâ directory: >>> >>> Pharo.image >>> Pharo.changes >>> ./pharo >>> â¦ and everything for âpharo working internallyâ here >>> >>> then users have again control about what they have along with the image >>> (this allows to some nice strategies too, when we want a version that >>> does >>> not pollutes the file dir). >>> >>> of course, this idea follows other developing spaces, where things are >>> stored in same fashion wayâ¦ for example in eclipse for java they store >>> all >>> eclipse data under .workspace directory. >>> >>> so, please note that this is NOT user spaceâ¦ regular pharo users will >>> store his files along with the image, for instance filetree >>> repositoriesâ¦ >>> something like: >>> >>> Pharo.image >>> Pharo.changes >>> .pharo/ >>> voyage/ >>> punqlite/ >>> etc. >>> >>> wellâ¦ I will commit a SLICE with the changes soon (is not a hard change >>> at all). >>> >>> But then: >>> >>> is ./pharo a good name? >>> will this work? >>> >>> Esteban >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> -- View this message in context: http://forum.world.st/Reordering-working-directory-mess-tp4902671p4903118.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 24, 2016

Re: [Pharo-dev] Reordering working directory mess

by Esteban Lorenzano

> On 24 Jun 2016, at 18:14, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > I agree with Javier, it would be much nicer to have only one shared package cache and, while I understand that there might be people not wanting that, I don't see why it couldn't be the default behavior. I think that it would be a reasonable default, don't you? I agreeâ¦ but where to store them? same place as âpreferencesâ? real problem with this is that you reduce a little bit âportabilityâ of Pharo, because you store files outside the root directoryâ¦ but we already do that, so I would agree :P Esteban > > On Fri, Jun 24, 2016 at 3:54 PM, Javier PimÃ¡s <elpochodelagente(a)gmail.com <mailto:elpochodelagente@gmail.com>> wrote: > I don't know for the new directories, but I always thought that it would be nice to have package-cache in ~/.pharo or a place shared by all images, to avoid redownloading all .MCZs from other projects each time you launch pharo from a different directory. > > Cheers! > Pocho > > On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi, > > Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this: > > Pharo.image > Pharo.changes > PharoDebug.log > pharo-cache > > now we have: > > Pharo.image > Pharo.changes > PharoDebug.log > pharo-cache > epicea-sessions > play-cache > play-stash > > it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory: > > Pharo.image > Pharo.changes > ./pharo > â¦ and everything for âpharo working internallyâ here > > then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir). > > of course, this idea follows other developing spaces, where things are stored in same fashion wayâ¦ for example in eclipse for java they store all eclipse data under .workspace directory. > > so, please note that this is NOT user spaceâ¦ regular pharo users will store his files along with the image, for instance filetree repositoriesâ¦ something like: > > Pharo.image > Pharo.changes > .pharo/ > voyage/ > punqlite/ > etc. > > wellâ¦ I will commit a SLICE with the changes soon (is not a hard change at all). > > But then: > > is ./pharo a good name? > will this work? > > Esteban > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires >

June 24, 2016