- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Strategies with Nautilus announcements

by Henrik Johansen

> On 13 Sep 2015, at 12:04 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 13 Sep 2015, at 11:59, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >>> >>> On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>>> >>>> On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>>> >>>> >>>> >>>> 2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>>> 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)? >>>> >>>> I didn't know announcments are working that way, but it may make sense if you want to group announcments (register once for "WindowAnnouncement" and receiving all kind of >>>> subannouncements (WindowClosed/WindowOpened â¦) >>> >>> I donât know about performance, but as far as I understand you can also subscribe to âWindowAnnouncement withAllSubclassesâ. >> >> That would be setting yourself up for a heap of duplicates. >> By design, you can subscribe twice to the same announcement and receive two notifications, so doing that will net you $InheritanceLevelsFromWindowAnnouncement copies of eachâ¦ > > My point was that maybe instead of making an implicit inheritance subscription we should make it explicit. So if you want to subscribe only to WindowAnnouncement and not to its subclasses, you can do that. If you wan to subscribe to the hierarchy you can do âWindowAnnouncement withAllSubclassesâ. Again, this is just an idea and I donât know how it impacts performance or some other things. I just see a limitation now that I cannot subscribe only to a class ignoring it subclasses without doing a check later. > > Uko If you do, you majorly break compatability with how announcements work in all other dialects. So in that case, better rename the framework at the same time. Cheers, Henry

Sept. 13, 2015

Re: [Pharo-dev] Strategies with Nautilus announcements

by Yuriy Tymchuk

> On 13 Sep 2015, at 11:59, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >>> >>> On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>> >>> >>> >>> 2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>> 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)? >>> >>> I didn't know announcments are working that way, but it may make sense if you want to group announcments (register once for "WindowAnnouncement" and receiving all kind of >>> subannouncements (WindowClosed/WindowOpened â¦) >> >> I donât know about performance, but as far as I understand you can also subscribe to âWindowAnnouncement withAllSubclassesâ. > > That would be setting yourself up for a heap of duplicates. > By design, you can subscribe twice to the same announcement and receive two notifications, so doing that will net you $InheritanceLevelsFromWindowAnnouncement copies of eachâ¦ My point was that maybe instead of making an implicit inheritance subscription we should make it explicit. So if you want to subscribe only to WindowAnnouncement and not to its subclasses, you can do that. If you wan to subscribe to the hierarchy you can do âWindowAnnouncement withAllSubclassesâ. Again, this is just an idea and I donât know how it impacts performance or some other things. I just see a limitation now that I cannot subscribe only to a class ignoring it subclasses without doing a check later. Uko > > Cheers, > Henry

Sept. 13, 2015

Re: [Pharo-dev] Strategies with Nautilus announcements

by Henrik Johansen

> On 12 Sep 2015, at 10:25 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> >> >> 2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >> 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)? >> >> I didn't know announcments are working that way, but it may make sense if you want to group announcments (register once for "WindowAnnouncement" and receiving all kind of >> subannouncements (WindowClosed/WindowOpened â¦) > > I donât know about performance, but as far as I understand you can also subscribe to âWindowAnnouncement withAllSubclassesâ. That would be setting yourself up for a heap of duplicates. By design, you can subscribe twice to the same announcement and receive two notifications, so doing that will net you $InheritanceLevelsFromWindowAnnouncement copies of each... Cheers, Henry

Sept. 13, 2015

Re: [Pharo-dev] [Pharo-users] Pillar 1.1.0 released

by Johan Brichau

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. 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. > On 07 Sep 2015, at 09:51, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > 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 >

Sept. 13, 2015

Re: [Pharo-dev] call "compress file " from the FileList

by Marcus Denker

> On 13 Sep 2015, at 00:26, Nicolai Hess <nicolaihess(a)web.de> wrote: > > There was a bug on compress file > (see issue https://pharo.fogbugz.com/f/cases/10235/StandardFileStream-compressFile-can… <https://pharo.fogbugz.com/f/cases/10235/StandardFileStream-compressFile-can…>) > > This is fixed know for Pharo 4.0, anyone knows why we can not call "compress file" > anymore in Pharo 5.0 ? > I think this could be a side effect (bug) from the new pragma based registration mechanism for registering actions in the FileList? Marcus

Sept. 13, 2015

call "compress file " from the FileList

by Nicolai Hess

There was a bug on compress file (see issue https://pharo.fogbugz.com/f/cases/10235/StandardFileStream-compressFile-can… ) This is fixed know for Pharo 4.0, anyone knows why we can not call "compress file" anymore in Pharo 5.0 ?

Sept. 12, 2015

Re: [Pharo-dev] "missing" exports on the windows vm

by Nicolai Hess

2015-05-21 20:35 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-05-06 0:11 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> We have a failing test case for NB >> NBInterpreterProxyTest>>#testStackPointer >> it fails because >> NativeBoost loadSymbol: 'stackPointerAddress' fromModule: NativeBoost >> VMModule >> returns nil >> >> This works for the linux vm! >> >> There are other methods that can be loaded, for example: >> (NativeBoost loadSymbol: 'primitiveAllObjects' fromModule: NativeBoost >> VMModule) >> -> returns an address. >> >> This stopped working for the windows pharo vm around june 2014. The >> source that >> changed is cointerp.h, the prior version had EXPORT(...) declarations >> around all >> functions in cointerp.h, the current version not. >> >> Three questions: >> >> 1. Why does this still work on linux? Does it export all functions >> declared in >> a header? >> 2. why was it changed? (I could not found the change in the code >> generator, maybe we >> exported all functions with pragma #api and now only those with pragma >> #export ? >> 3. do we need this function to be exported? Apart from this testcases, >> this method is >> called the on image startup, but the nil return does not harm. >> It seems it is not part of the main vm api (like the interpreter proxy >> functions callable from external modules) and I didn't see code thet depend >> on this. >> >> There are similiar functions for which we load the function address on >> startup: >> cStackPointerAddress and cFramePointerAddress, this seems to work, but I >> don't know if the expected result is different. >> >> In NBInterpreterProxy>>#initialize, we try to load all fourmethods: >> stackPointerAddress/framePointerAddress -> nil >> cStackPointerAddress / cFramePointerAddress -> not nil >> >> >> >> nicolai >> >> > > Anyone knows why the exports changed on windows? > Or if we need the stackPointerAddress/framePointerAddress methods? > > Maybe I'll just close the issue as won't fix. On the other hand, we now have this failing test (skipped for windows), so maybe I will remove the test. But still, I would like to know if this change was by accident or on purpose. If it was on purpose, maybe there is a way to make this test succeed on windows too? > > nicolai > >

Sept. 12, 2015

Re: [Pharo-dev] Strategies with Nautilus announcements

by stepharo

>> What we could do (maybe this is a bit overkill): >> >> - make an announcements hierarchy (NautilusPackageAnnouncement -> >> NautiulusClassAnnouncement ...) but never subscribe to this Announcemnts >> - create sub classes for every "kind" >> NautilusPackageAnnouncement subclass: NautilusPackageChangedAnnouncement >> NautilusPackageAnnouncement subclass: NautilusPackageSelectedAnnouncement >> >> NautilusClassAnnouncement subclass: NautilusClassSelectedAnnouncement >> NautilusClassAnnouncement subclass: NautilusClassChangedAnnouncement >> >> And only subscribe to this subclasses. >> That way we are using the hierarchy of Announcement classes for >> removing of duplicated code, but only >> register and announce the "leaf"-nodes >> (NautilusClassChangedAnnouncement / >> NautilusPackageChangedAnnouncement...) >> >> what do you think? > > This may do. Also another option would be to have > a NautilusSelectionAnnouncement with all 4 attributes, and then just > subclass it for a different type. Yes this solution is less verbose and has my preference. stef

Sept. 12, 2015

Re: [Pharo-dev] Strategies with Nautilus announcements

by Yuriy Tymchuk

> On 12 Sep 2015, at 17:34, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-09-09 14:32 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > 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)? > > I didn't know announcments are working that way, but it may make sense if you want to group announcments (register once for "WindowAnnouncement" and receiving all kind of > subannouncements (WindowClosed/WindowOpened â¦) I donât know about performance, but as far as I understand you can also subscribe to âWindowAnnouncement withAllSubclassesâ. > > What we could do (maybe this is a bit overkill): > > - make an announcements hierarchy (NautilusPackageAnnouncement -> NautiulusClassAnnouncement ...) but never subscribe to this Announcemnts > - create sub classes for every "kind" > NautilusPackageAnnouncement subclass: NautilusPackageChangedAnnouncement > NautilusPackageAnnouncement subclass: NautilusPackageSelectedAnnouncement > > NautilusClassAnnouncement subclass: NautilusClassSelectedAnnouncement > NautilusClassAnnouncement subclass: NautilusClassChangedAnnouncement > > And only subscribe to this subclasses. > That way we are using the hierarchy of Announcement classes for removing of duplicated code, but only > register and announce the "leaf"-nodes (NautilusClassChangedAnnouncement / NautilusPackageChangedAnnouncement...) > > what do you think? This may do. Also another option would be to have a NautilusSelectionAnnouncement with all 4 attributes, and then just subclass it for a different type. Uko > > > > > > > > > Uko >

Sept. 12, 2015

Re: [Pharo-dev] [Vm-dev] Re: Maintainer of FFI-Package

by Nicolai Hess

2014-09-28 22:04 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > Thank you David, > Thank you Eliot > > 2014-09-28 21:24 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Hi Nicolai, >> >> On Sep 28, 2014, at 2:19 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> > Who is the maintainer of the FFI-Package for >> > Squeak and/or Pharo ? >> >> I guess I'm the de facto maintainer because I'm the one who has changed >> things most recently, reimplementing the FFI plugin via the >> ThreadedFFIPlugin. >> >> >> > 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) >> >> Can you give me a reproducible case? I'd this with a Cog,Stack or >> Interpreter VM? Which specific things fail and how? >> > > Image > ----- > > /home/nicolai/Downloads/Squeak-4.5-All-in-One.app/Contents/Resources/Squeak4.5-13680.image > Squeak4.5 > latest update: #13680 > Current Change Set: Unnamed1 > Image format 6505 (32 bit) > > Virtual Machine > --------------- > > /home/nicolai/Downloads/Squeak-4.5-All-in-One.app/Contents/Linux-i686/lib/squeak/4.0-2776/squeak > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] > Unix built on Aug 22 2013 10:35:37 Compiler: 4.1.2 20080704 (Red Hat > 4.1.2-48) > platform sources revision VM: r2776 > http://www.squeakvm.org/svn/squeak/branches/Cog Plugins: r2545 > http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins > CoInterpreter VMMaker.oscog-eem.331 uuid: > 37d2e4b0-2f37-4e2d-8313-c63637785e59 Aug 22 2013 > StackToRegisterMappingCogit VMMaker.oscog-eem.333 uuid: > 84da9cb8-7f30-4cb7-b4fb-239a11f63b54 Aug 22 2013 > > Load > Name: FFI-Pools-eem.3 > Name: FFI-Kernel-eem.26 > Name: FFI-Tests-djm.7 > > Run FFI-Test -> 32 run, 24 passes, 0 expected failures, 0 failures, 8 > errors, 0 unexpected passes > > Load > Name: FFI-Unix-mtf.4 > > run X11Display class>>#coloredRectangles > -> Error: Could not coerse arguments > > Load newer cogvm > Virtual Machine > --------------- > > /media/Programs/squeak/Squeak-4.5-All-in-One.app/coglinux/lib/squeak/4.0-2987/squeak > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.746] > Unix built on Jun 11 2014 14:59:18 Compiler: 4.1.2 20080704 (Red Hat > 4.1.2-48) > platform sources revision VM: r2987 > http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2014-06-11 14:26:16 > -0700 Plugins: r2954 > http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins > CoInterpreter VMMaker.oscog-eem.746 uuid: > cc4961d3-e629-4e28-b308-88eab314a8c9 Jun 11 2014 > StackToRegisterMappingCogit VMMaker.oscog-eem.766 uuid: > 3045c341-cfbf-494c-a7b1-fb29c26a7340 Jun 11 2014 > > Run FFI-Test -> 32 run, 32 passes, 0 expected failures, 0 failures, 0 > errors, 0 unexpected passes > > > The error in FFI-Unix is strange. The last package comment from > Name: FFI-Unix-mtf.4 > Author: mtf > is > "made the XLib examples actually work (Window is an unsigned int handle, > not a struct)" > > That the window is an int handle and not a struct explains why this > version replaces the parent class > of XDrawable from ExternalStructur to Object. But all calls with an > XDrawable still have this > object as parameter ( and not its instance var "xid"). I don't understand > how this ever > worked (or was there some kind of automatic argument conversion like: > transform an object with an instvar -> a int, if the function expects an > int handle?) > > Sure we can replace all XDrawable arguments in X11 calls from "aXDrawable" > to "aXDrawable xid". > But I only wonder, did this ever work and if Author "mtf" did the last > change, can I contact > him or is he still maintaining the FF-Unix examples? > > I would like to raise this topic again. Nothing has changed, the linux example still don't work and I can not get information about who maintains the unix-examples. >From my analysis (see above), the fix may be simple (in another discussion around that time some one else asked how to make that working, and confirmed it works with that fix). But I am confused because the latest update for the examples had the comment "made the XLib examlpes actually work". So maybe my usage or version of FFI is wrong. The last time I asked, someone said this works for him with the current stable vm, but it was actually the latest cog vm he used. But now, a year later, with the current 4.6 cog and 5.0 spur vm, some FFI unit tests still failing so maybe I am using the wrong FFI package (FFI-Kernel-EstebanLorenzano.27) ? (BTW, there is a typo in ExternalAddress class >> loadSymbol: moduleSymbol module: module <primitive: 'primitiveLoadSymbolFromModule' module: 'SqueakFFIPrims'> ^ self primitiveFail it should call ^ self primitiveFailed > > > > >> > regards >> > Nicolai >> >> Eliot (phone) > > >

Sept. 12, 2015