September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] Pillar 1.1.0 released
by Damien Cassou Sept. 13, 2015

Sept. 13, 2015

Hi Johan, Ferlicot Delbecque Cyril <c.ferlicot-delbecque(a)etudiant.univ-lille1.fr> writes: > Le 13/09/2015 10:28, Johan Brichau a Ã©crit : >> I just noticed that in the most recent version of Pillar, the instvar >> #embedded was removed from PRReference This breaks Pierâ¦ though right >> before this change I could make Pier3 work with Pillar just fine. >> >> The embedded var is used to specify that component references are to >> be embedded in the page. There are more components than Figures in >> Pier. >> > We removed that because since Figures are not link anymore we do not > need it. If the reference is a link, it is not embedded, else it is. > We plan latter to have more embedded item than Figures, maybe we can > just and a class between Reference and Figure (PREmbeddedReferences). > With that we do not need the ivar. > > But since Pier3 doesn't evolve anymore I proposed to someone to freeze > the version of Pillar needed for the stable version of Pier3. But I > didn't get an answer. I totally agree with Cyril. We can't limit the development of a dependency forever because a dependent has more or less stopped evolving. Before, a figure was a link with embedded = true. This was silly because each visitor had to do something specific for figures (e.g., in html you want a <img>, in latex you want \includegraphics). This is totally different from what is expected of a link. Now a figure is not a link anymore, it is a reference. There can be multiple kinds of references but the embedded parameter what not of any use for Pillar anymore. So we decided to remove it, knowing that Pier used it to embed Pier components. So, Pier users have 2 solutions now: - either adapt Pier's configuration so that it uses an old version of Pillar; - or adapt Pier's code to rely on the new Pillar. This might require some adaptations to Pillar which we can discuss. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

1 0

Fwd: Re: [Pharo-users] Pillar 1.1.0 released
by Ferlicot D. Cyril Sept. 13, 2015

Sept. 13, 2015

Le 13/09/2015 10:28, Johan Brichau a Ã©crit : > Hi, > > I just noticed that in the most recent version of Pillar, the instvar #embedded was removed from PRReference > This breaks Pierâ¦ though right before this change I could make Pier3 work with Pillar just fine. > > The embedded var is used to specify that component references are to be embedded in the page. There are more components than Figures in Pier. > Hi Johan, We removed that because since Figures are not link anymore we do not need it. If the reference is a link, it is not embedded, else it is. We plan latter to have more embedded item than Figures, maybe we can just and a class between Reference and Figure (PREmbeddedReferences). With that we do not need the ivar. But since Pier3 doesn't evolve anymore I proposed to someone to freeze the version of Pillar needed for the stable version of Pier3. But I didn't get an answer. -- Cyril > I am just trying to use and work with Pier3 for Seaside book and website, so it would be great if you can consider adding the embedded variable again. > > thanks guys! > Johan > > ps: email me directly, since I might miss replies via the mailinglist. > >

1 0

Annotating instance variables
by HernÃ¡n Morales Durand Sept. 13, 2015

Sept. 13, 2015

I saw some interesting reflection progress in Pharo 5. I wonder if there is a feature to rank instance variables. For example, from the browser I want to assign a category "important" to an instance variable, or "possibly useless", etc. for later refactorings. Is such thing "easily" possible now? There is API support from Reflectivity maybe? Cheers HernÃ¡n

4 6

Strategies with Nautilus announcements
by Yuriy Tymchuk Sept. 13, 2015

Sept. 13, 2015

Hi, as NautilusMethodSelected contains also an information about protocol, class, package; NautilusProtocolSelected contains an information about class and package; . . . Iâve inherited NautilusClassSelected from NautilusPackageSelected and NautilusProtocolSelected from NautilusClassSelectedâ¦ to remove duplication. But as announcement subscription also includes itâs subclasses, if you subscribe to NautilusPackageSelected, you end up receiving also NautilusClassSelected, NautilusProtocolSelected and NautilusMethodSelected. What is a good way to resolve this (I can simply separate all the classes, but maybe there is something important from conceptual point of view)? Uko

4 9

Pillar 1.1.0 released
by Damien Cassou Sept. 13, 2015

Sept. 13, 2015

Cyril Ferlicot and I have polished Pillar 1.0.0 a little. Here is 1.1.0 changelog: - add shebang to generated pillarPostExport.sh - improve pillarPostExport.sh messages a little - HTML exporter - output a <figure> if and only if the Pillar figure has both a caption and a label - LaTeX exporter - output a \begin{figure} if and only if the Pillar figure has both a caption and a label Cyril migrated the list of issues and feature requests from smalltalkhub.com to https://github.com/pillar-markup/pillar/issues Please report issues, describe feature requests and ask questions there. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

2 1

Maintainer of FFI-Package
by Nicolai Hess Sept. 12, 2015

Sept. 12, 2015

Who is the maintainer of the FFI-Package for Squeak and/or Pharo ? I especially interested in the FFI-Unix examples and the state on working FFI on linux for current squeak release (AFAIK it does not work with "squeak all in one" 4.5) regards Nicolai

3 6

Bootstrap dependency, System-Announcements --> PragmaCollector
by Ben Coman Sept. 12, 2015

Sept. 12, 2015

The bootstrap-dependency graph and report [1] mark dependency System-Announcements --> PragmaCollector for pruning. This is due to... SystemAnnouncer>>restoreAllNotifications | collector | self reset. collector := PragmaCollector filter: [ :pragma | pragma keyword = #systemEventRegistration ]. collector reset. collector do: [ :pragma | pragma methodClass theNonMetaClass perform: pragma selector ] Browsing around I came to understand that PragmaCollector is useful as a pragma cache, but here the collector is thrown away, so that facility is not needed. A key part is "collector reset" which does... self class allSystemPragmas do: [:pragma | self addPragma: pragma] where the #addPragma: evaluates the initialize'd #filter: block. Now it seems that #allSystemPragmas might fit nicely on Pragma rather than PragmaCollector such that the following should be equivalent... SystemAnnouncer>>restoreAllNotifications | systemPragmas | self reset. systemPragmas := Pragma allSystemPragmas collect: [ :pragma | pragma keyword = #systemEventRegistration ]. systemPragmas do: [ :pragma | pragma methodClass theNonMetaClass perform: pragma selector However #allSystemPragmas depends on SystemNavigation, so is it be okay for Pragma to depend on SystemNavigation? Actually, class side of Pragma has several #named:in: like methods, so something like the following would be neat... SystemAnnouncer>>restoreAllNotifications self reset. Pragma allNamed: #systemEventRegistration do: [ :pragma | pragma methodClass theNonMetaClass perform: pragma selector ]. cheers -ben [1] https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM…

5 11

Re: [Pharo-dev] [squeak-dev] Criteria For Plugin Compatibility
by Eliot Miranda Sept. 11, 2015

Sept. 11, 2015

Hi Chris, On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <brasspen(a)gmail.com> wrote: > I had the idea that a plugin from one VM could be dragged into another > VM's directory and that it could be used just by starting up the image. > I've done a little experimenting and it seems more of an idea of a reality. > The functionality is there, but VM developers over the years have not seen > this as a priority. Typically plugins and their VMs are compiled together. > Or a person adds one by recompiling a VM compilation rig they already have. > The problems I see with this are a) a plugin compiled for Spur may not work with V3 or vice verse. The issue is the header size of an object. Some plugins, but not all, use this define, and the header sizes between Spur and V3 are incompatible. b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't work with 32-bit VMs. Period. Now there are platform-level packaging technologies, such as fat binaries on Mac OS X, that allow one to construct plugins that contain more than one binary. But this is a lot of work to build and maintain. So personally I wouldn't put much effort into this level of drag-and-drop compatibility. Instead I'd put energy into good error messages so that when plugins don't work the user can find out why, and that when the wrong kind of plugin is used the VM doesn't just stumble along, maybe producing incorrect results, but instead puts the plugin out with a comprehensible complaint. Does this make sense? I know its a downer, but what you propose is, IMO, not affordable given our resources. And I must say, *this is a VM-DEV discussion, not a general purpose Squeak discussion*, yes? As I had a rig for the Interpreter VM I decided to compile a plugin and see > if I could drag it around to other VM directories for use. Most times it > didn't work. > > I compiled a TheUniversalAnswer plugin which returns 42. I moved it from a > 4.14.1-3430 VM to a 4.14.1-3414 VM. I could get it to work if I did not use > the squeak.sh start script. That is, I dragged so.vm-sound-null, > so.TheUniversalAnswer and so.vm-display-X11 into the same directory as the > VM binary. That worked. > > The only way to see the external plugins is with #listLoadedModules. But, > irritatingly, modules are loaded as needed, so once you have proof of using > the primitive from the plugin, yea, it will appear as a result of that > Smalltalk listLoadedModules message. So, it's not that useful. > > I dragged so.TheUniversalAnswer around to other VMs such as 4.0.3-2202 and > 4.13.10-3268 without success. And the unload selectors #forgetModule: and > unloadModule:, which both use primitive 571 don't appear to work on my > Ubuntu 15.04. > > So, I don't know if a community of plugins passed around is in the offing. > What I have learned is that many of the answers are in > sqUnixExternalPrims.c. The issues are really where does the VM look for > primitives and what does it do when it finds one. It appears to me, after > reading both the non-Cog and Cog versions of that file, that this an > interesting area poorly documented that VM developers alter in haste to get > on to something else. > > It's pretty important stuff, though. Do you start the VM with the binary > on the path? Do you use squeak.sh? Where is the VM looking for stuff. Where > will FFI look for stuff. And so on. > > Chris > > > > -- _,,,^..^,,,_ best, Eliot

2 1

Running a test method in Nautilus
by Alexandre Bergel Sept. 11, 2015

Sept. 11, 2015

Hi! I can run a test method by pressing the button located on the left hand side of the method name. If the test fail, it does not open a debugger. I need to run it a second time. This is a rather odd behavior. Am I the only one to experience this? Side question: I try to check on the bug tracker if there is something about that, but I was not able to find it. I entered in the search input field the tree keywords: test button nautilus The result is https://pharo.fogbugz.com/f/search/?sSearchFor=test+button+nautilus However, this indicates many closed issues. How can I filter out the close issues? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 6

[Reflectivity] Progress with Reifications
by Marcus Denker Sept. 11, 2015

Sept. 11, 2015

Hi, in Pharo5 #120 we have lots of progress with Reflectivity regarding to âreificated valuesâ. 1) more reificated value are working. #arguments - an array of the arguments of a message send or method #receiver - receiver of a message (or method executed) #context for Methods #sender for method and message This means we have now all the info needed to e.g. pass all date needed to do a message send on the meta level. (receiver, args, selector), or a variable store (#name, #newValue). 2) Reifications as arguments to conditions. When the block used as a condition has arguments, the name is matched to the possible reifications and if valid this value is passed as an argument. Very useful e.g. for object specific links: link := MetaLink new condition: [: object | object == <the object I am intersted in>]; metaObject: <someObject>; selector: <some selector> This link would only be active for this one object. 3) Reifications as meta object ------------- Every valid reified value can be the metaobject of the link. e.g. you can now define a link where the meta is the node where the Link is installed: link := MetaLink new metaObject: #node; selector: #tagHasBeenExecuted. Or the #receiver: link := MetaLink new metaObject: #receiver; selector: #perform:withArguments:; arguments: #(selector arguments). TODO -> #slot, #global. #variable reifications -> #after needs to wrap in ensure: -> primitives -> more tests -> optimize link preambles: when reifying both #arguments and #receiver, merge the preamble into one for performance.

3 4