November 2018 - Pharo-users

Re: [Pharo-users] Loading Metacello with Seaside

by Vitor Medina Cruz

It worked, appears to be an error with Magritte so. I wish I had this page describing how to use Baselines three months ago! It is VERY well made. :) On Wed, Nov 28, 2018 at 4:45 PM Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > "I tried to load magritte only and I got the same problem. Maybe I do not >> have it in my project because I load seaside before with an other group?" >> > > Probably > > "You can try to add seaside yourself in your project. Something like:" >> > > I will try that :( > > > On Wed, Nov 28, 2018 at 3:22 PM Cyril Ferlicot D. < > cyril.ferlicot(a)gmail.com> wrote: > >> Le 28/11/2018 Ã 17:38, Vitor Medina Cruz a Ã©crit : >> > Tried now, didn't work, same error. It is working for you? >> > >> >> I tried to load magritte only and I got the same problem. Maybe I do not >> have it in my project because I load seaside before with an other group? >> >> I think there was an issue that is fixed in the dev version of Seaside >> about that. It should be in the next release. >> >> You can try to add seaside yourself in your project. Something like: >> >> baseline: spec >> <baseline> >> spec >> for: #common >> do: [ >> spec >> baseline: 'Seaside3' with: [ spec repository: >> 'github://SeasideSt/Seaside/repository' ]; >> baseline: 'Magritte' >> with: [ spec >> loads: #('Seaside' 'Core'); >> repository: >> 'github://magritte-metamodel/magritte:v3.5.3/source' ]. >> spec package: 'Employees' with: [ spec requires: #('Seaside3' >> 'Magritte') ] ] >> >> >> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >>

Nov. 30, 2018

Re: [Pharo-users] UFFI and opaque(ish) types

by Esteban Lorenzano

> On 30 Nov 2018, at 19:50, phil--- via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: "phil(a)highoctane.be" <phil(a)highoctane.be> > Subject: Re: [Pharo-users] UFFI and opaque(ish) types > Date: 30 November 2018 at 19:50:03 CET > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > Inherit from FFIOpaqueObject > > + initialize TypeMap > > I have a few here: > > https://github.com/Pharophile/XmppTalk <https://github.com/Pharophile/XmppTalk> > > https://github.com/Pharophile/XmppTalk/tree/master/packages/XmppTalk-Extern… <https://github.com/Pharophile/XmppTalk/tree/master/packages/XmppTalk-Extern…> > https://github.com/Pharophile/XmppTalk/blob/master/packages/XmppTalk-LibStr… <https://github.com/Pharophile/XmppTalk/blob/master/packages/XmppTalk-LibStr…> > > HTH > Phil Yes, as he says/shows :) Esteban > > > > On Fri, Nov 30, 2018 at 2:39 PM Alistair Grant <akgrant0710(a)gmail.com <mailto:akgrant0710@gmail.com>> wrote: > How are opaque(ish) types normally handled in UFFI (or FFI)? > > E.g. if I want to use libstuff which defines the following structure: > > struct stuffstruct { > typeA a; > typeB b; > } stufftype; > > > I might know they're integers, but not the size, signed vs. unsigned, > etc. > > The definitions of typeA and typeB are buried in multiple layers of > header files, dependent on #if tests, can be different sizes on > different platforms (e.g. Linux vs. MacOS), etc.? > > Is this documented somewhere? > > Thanks, > Alistair > > > >

Nov. 30, 2018

Re: [Pharo-users] [squeak-dev] Named serial port bug and how to contribute

by William L. Cleveland

Thanks for the clarification. On Windows 10, I also had problems. Managed on one occasion to get firmata isConnected to return True, but writing to a port had no effect. I got multiple error messages; I think one of them referenced a SerialPiort primitive, consistent with your findings. Playing with VMs is beyond me, so I will give PyFirmata a try. With much appreciation, Lou Cleveland > On Nov 30, 2018, at 2:42 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > Good to know! > > Am Fr., 30. Nov. 2018 um 02:25 Uhr schrieb Ricardo Moran <richi.moran(a)gmail.com <mailto:richi.moran@gmail.com>>: > Hi, > > I think I found a bug with the named serial ports in windows. > I can open a named port without problem the first time but if I close it and try to open it again it fails until I restart the image. This doesn't happen with numeric ports. I could reproduce this bug in both Squeak5.2 and Pharo6.1 (both using windows 8.1). > > I think the problem is that SerialPort>>#primClosePortByName: calls the "primitiveSerialPortCloseByName" but I couldn't find this primitive anywhere in the SerialPlugin source (https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Seri… <https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Seri…>). So I'm guessing that the port is never properly closed. > > I added the missing primitive (find attached) and recompiled the vm, and now it seems to work. So my question is: how can I contribute this small fix? Should I commit to the VM Maker Inbox repository? > > Thanks, > Richo >

Nov. 30, 2018

Re: [Pharo-users] UFFI and opaque(ish) types

by phil＠highoctane.be

Inherit from FFIOpaqueObject + initialize TypeMap I have a few here: https://github.com/Pharophile/XmppTalk https://github.com/Pharophile/XmppTalk/tree/master/packages/XmppTalk-Extern… https://github.com/Pharophile/XmppTalk/blob/master/packages/XmppTalk-LibStr… HTH Phil On Fri, Nov 30, 2018 at 2:39 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > How are opaque(ish) types normally handled in UFFI (or FFI)? > > E.g. if I want to use libstuff which defines the following structure: > > struct stuffstruct { > typeA a; > typeB b; > } stufftype; > > > I might know they're integers, but not the size, signed vs. unsigned, > etc. > > The definitions of typeA and typeB are buried in multiple layers of > header files, dependent on #if tests, can be different sizes on > different platforms (e.g. Linux vs. MacOS), etc.? > > Is this documented somewhere? > > Thanks, > Alistair > > >

Nov. 30, 2018

Re: [Pharo-users] Unable to compile myself Pharo

by Alexandre Garreau

Hi, I tried to compile itself because Iâm usually incomfortable with using binaries downloaded from the internet whose sources couldnât be checked afterwards. I donât know the status of Pharo regarding Deterministic Builds, but I have come anyway to become more comfortable in trusting what comes from the distro I use and only thatâ¦ But I saw the bootstrap process involve redownloading a binary image anywayâ¦ Iâd have just prefered to recompile it to be sure, as Iâm usually more comfortable with this idea. Normally compiling a new language is âthough longâ not that difficult. So maybe that could help debugging stuff that might be improved? I guess that error is not supposed to happen right? PS: sorry for the late answer, I didnât see answers at first, mails were only sent to the list and Iâm often more used to have answers to me be cc to myself. I guess the usage is different here.

Nov. 30, 2018

UFFI and opaque(ish) types

by Alistair Grant

How are opaque(ish) types normally handled in UFFI (or FFI)? E.g. if I want to use libstuff which defines the following structure: struct stuffstruct { typeA a; typeB b; } stufftype; I might know they're integers, but not the size, signed vs. unsigned, etc. The definitions of typeA and typeB are buried in multiple layers of header files, dependent on #if tests, can be different sizes on different platforms (e.g. Linux vs. MacOS), etc.? Is this documented somewhere? Thanks, Alistair

Nov. 30, 2018

Re: [Pharo-users] Reify RBLiteralNode and RBBlockNode args/return with MetaLink?

by Marcus Denker

>> >> Steven did a version that is based on AST transformation only, we will explore that direction further in the future. > > Interesting, so this would be the one I'd like to see (because I > implemented with AST transforms). Would you have a link to his work? > Mine is on github, and the version I did at UBO was on the VisualWorks > AST. > https://github.com/StevenCostiou/Reflectivity-Flatteners <https://github.com/StevenCostiou/Reflectivity-Flatteners> I want to look at that for real after finishing some things in the current version. Marcus

Nov. 30, 2018

Re: [Pharo-users] Lambda World 2018 - What FP can learn from Smalltalk by Aditya Siram

by askoh

Would it be easy to make Smalltalk ideal for Functional Programming so that the FP community is attracted to the Smalltalk IDE? It would be a shame for them to invent another half baked IDE. All the best, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 30, 2018

Re: [Pharo-users] Reify RBLiteralNode and RBBlockNode args/return with MetaLink?

by Thierry Goubier

Le ven. 30 nov. 2018 Ã 10:31, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > > > > On 29 Nov 2018, at 12:55, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > Le jeu. 29 nov. 2018 Ã 11:15, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > >> > >> > >> > >>> On 29 Nov 2018, at 10:45, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > >>> > >>> Hi Manuel, > >>> > >>> would that extend to testing what happens if you add many, many > >>> metalinks in a method? > >>> > >> > >> yes, it would be nice to test that. > >> > >> > >>> I tried to rewrite the automated code tracer I had to use metalinks, > >>> and I gave up once I discovered that going over a certain number of > >>> metalinks in a method would stop working. > >>> > >> > >> > >> If you add a lot of code, you need to use the new byte code set as the old one is extremely limited for everything (number of temps, jump offsetâ¦) > > > > Well, it failed before that limit; once the context was complex > > enough, it would fail in various ways, such as being unable to bind to > > the proper temporary, writing incorrect byte sequences, and so on > > > > I think the changes we did will make that betterâ¦ > > > As anyway, it was injecting the same code that my tracer was already > > doing, but in a less debuggable way, so I sort of gave up and kept > > MetaLink use to simpler things, such as a type checker that inject > > type checks on arguments based on the type inferred from arguments > > names. > > > > Now, when I see how you're improving metalinks in this thread, I'd be > > interested in a higher view (source-level) of the transformations > > you're doing for implementing metalinks: I think they then could be > > reused in different contexts (i.e. refactorings, for example), or > > generalised outside Smalltalk itself. It may probably already been > > expressed that way, but I haven't looked into the metalink code > > itself. > > > > For now it is implemented as a special compiler (with âself emitAfter: aNodeâ) added in overriden methods of the main compiler. > > I made the mistake of doing some stuff (after links, for example) directly in the IR level, that did not work. > > Now this is fixed for all but the links for Sequences (to be done later). > > Steven did a version that is based on AST transformation only, we will explore that direction further in the future. Interesting, so this would be the one I'd like to see (because I implemented with AST transforms). Would you have a link to his work? Mine is on github, and the version I did at UBO was on the VisualWorks AST. Thierry > Marcus

Nov. 30, 2018

Re: [Pharo-users] Reify RBLiteralNode and RBBlockNode args/return with MetaLink?

by Marcus Denker

> On 29 Nov 2018, at 12:55, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le jeu. 29 nov. 2018 Ã 11:15, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : >> >> >> >>> On 29 Nov 2018, at 10:45, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Hi Manuel, >>> >>> would that extend to testing what happens if you add many, many >>> metalinks in a method? >>> >> >> yes, it would be nice to test that. >> >> >>> I tried to rewrite the automated code tracer I had to use metalinks, >>> and I gave up once I discovered that going over a certain number of >>> metalinks in a method would stop working. >>> >> >> >> If you add a lot of code, you need to use the new byte code set as the old one is extremely limited for everything (number of temps, jump offsetâ¦) > > Well, it failed before that limit; once the context was complex > enough, it would fail in various ways, such as being unable to bind to > the proper temporary, writing incorrect byte sequences, and so on > I think the changes we did will make that betterâ¦ > As anyway, it was injecting the same code that my tracer was already > doing, but in a less debuggable way, so I sort of gave up and kept > MetaLink use to simpler things, such as a type checker that inject > type checks on arguments based on the type inferred from arguments > names. > > Now, when I see how you're improving metalinks in this thread, I'd be > interested in a higher view (source-level) of the transformations > you're doing for implementing metalinks: I think they then could be > reused in different contexts (i.e. refactorings, for example), or > generalised outside Smalltalk itself. It may probably already been > expressed that way, but I haven't looked into the metalink code > itself. > For now it is implemented as a special compiler (with âself emitAfter: aNodeâ) added in overriden methods of the main compiler. I made the mistake of doing some stuff (after links, for example) directly in the IR level, that did not work. Now this is fixed for all but the links for Sequences (to be done later). Steven did a version that is based on AST transformation only, we will explore that direction further in the future. Marcus

Nov. 30, 2018