- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] macOS Sierra support

by stepharo

>>> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. >> it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again. >> >> Norbert > Yeah, but this is silly: it goes against the principle of a persistence format: to save data for future use. [ I knew this already, I never agreed with this principle ]. Me too - believe but my scenario was not really heard. I think that it would be good to have some strategies to represent different objects representation but fuel will be slower. Mariano was fighting against speed and speed and speed. and he did it well. > Like I described in the email, after upgrading, we were unable to run the old image - catch 22.

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by Max Leske

Hi Sven, An experimental build of the VM works again on Sierra (Iâve tested this one: https://bintray.com/estebanlm/pharo-vm/build/201609201407#files <https://bintray.com/estebanlm/pharo-vm/build/201609201407#files>). The problem was with the bundle code and a change from Appleâs side to Cocoa. The new VM is a Spur VM of course. If you need a Cog VM, you can try a Squeak VM (e.g. 'Croquet Closure Cog VM [CoInterpreterPrimitives VMMaker.oscog-eem.1095] Squeak Cog 4.0.3282â) or run the current PharoVM in a virtual machine on Linux (as Iâve done). Concerning Fuel: the versioning problem is a known and big issue I have to admit. Which Fuel versions does your problem concern? There were some big changes for Fuel from Pharo 4 to 5, e.g. MethodContext was renamed to Context. Depending on the objects you store however, you may be able to load the file simply by removing the version check in Fuel, as most things should be identical. Cheers, Max > On 27 Sep 2016, at 11:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 27 Sep 2016, at 11:21, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Sven, >> >>> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. >> >> it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again. >> >> Norbert > > Yeah, but this is silly: it goes against the principle of a persistence format: to save data for future use. [ I knew this already, I never agreed with this principle ]. > > Like I described in the email, after upgrading, we were unable to run the old image - catch 22. > > >

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by stepharo

Hi Sven > Hi, > > Can someone who really knows/understand please describe where to find the necessary Pharo VM's to run on the newly released macOS Sierra (10.12) ? I will let Esteban reply. > In particular it seems old VM's just stop working and recent VM's that do work either have issues or cannot run older (3.0, 4.0) images. But you see Pharo 50 got all the internal object representation changed. It happens only every 15 years or more. This is not an easy changes. We did not rewrote a new FFI just because we did not know what to do. The new format open so many future opportunities but it has a cost. Well if mac changes some important low-level entries why the VM would not be impacted. Esteban is working on - 64 bits support - ARM VM - after he should work on the FT plugin Now I think that he is quite efficient as engineers and it means that the community should help or put more money on the table to get more engineers. > Thanks, > > Sven > > PS: I have not yet upgraded, but one of my colleagues did and he got stuck: even after we found a VM that worked, it could only run 5.0 images, not his production 4.0 images. Needless to say, this is not good. > > PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. I was really concerned by that since Fuel inception. I agree with you. I think that a serialization format should live over multiple versions. Now this is difficult to achieve when the serializer is drastically optimised and rely on internal representation logic. And manpower of course. What the Script Manager should do is to provide a textual output too like using STON.

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by Sven Van Caekenberghe

> On 27 Sep 2016, at 11:21, Norbert Hartl <norbert(a)hartl.name> wrote: > > Sven, > >> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. > > it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again. > > Norbert Yeah, but this is silly: it goes against the principle of a persistence format: to save data for future use. [ I knew this already, I never agreed with this principle ]. Like I described in the email, after upgrading, we were unable to run the old image - catch 22.

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by Norbert Hartl

Sven, > Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again. Norbert

Sept. 27, 2016

macOS Sierra support

by Sven Van Caekenberghe

Hi, Can someone who really knows/understand please describe where to find the necessary Pharo VM's to run on the newly released macOS Sierra (10.12) ? In particular it seems old VM's just stop working and recent VM's that do work either have issues or cannot run older (3.0, 4.0) images. Thanks, Sven PS: I have not yet upgraded, but one of my colleagues did and he got stuck: even after we found a VM that worked, it could only run 5.0 images, not his production 4.0 images. Needless to say, this is not good. PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor.

Sept. 27, 2016

Re: [Pharo-dev] Off Topic: Children 3-13yr english program -- 4 weeks free access

by Ben Coman

On Tue, Feb 2, 2016 at 9:04 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Jul 20, 2015 at 11:17 PM, Ben Coman <btc(a)openinworld.com> wrote: >> greetings all, >> >> This is a long way off topic, but a random chance someone in the community >> with kids learning english may find it useful. The past year I've had my 4yr >> & 6yr old girls doing Reading Eggs. Its aimed at native-english children >> ages 3-13 (starting with a test to place kids at a stimulating level). >> >> Its been beneficial for my kids, so I'm forwarding this offer to the >> community. > > There was some appreciation for this six months ago. Another just > arrived, so I thought I'd share it again. In another half year I > guess I'll get another, so if anyone doesn't want me to post again > then, let me know. > > More background info... ABC is Australia's government sponsored > national TV broadcaster (yay, no commercials!). They produced a web > site to help kids literacy. It was fantastic for my kids, although my > 8 year old got bored with it later on, so it seems more suited for > younger ages. I've had no complaints (yet), and six months later another 5 week free pass arrived. I am a bit hesitant to continue forwarding them since its so far off topic, but I think there is real value for my online friends. http://readingeggs.com.au/pas2/?M=A2CC1945-52FE-4E22-8C1A-1614649ECE83 My youngest (now 6) is starting to get a bit bored with the final 20 levels (of 120) so again it seems to work better for the younger kids. Non-native-english kids may differ. btw, you don't need the book packs. They are all included in the online app. cheers -ben

Sept. 27, 2016

Re: [Pharo-dev] [REMEMBER] Tech meeting rue 27/09 16UTC - We'll talk about current PharoVM ongoing development

by stepharo

> I noticed only in a side conversation recently (rather than an > announcement, did I miss something?) that the change of development > process to now just submit slices to inbox and configurations get > sorted later (which makes things simpler - but I wonder how > configurations are then maintained. Manually would seem susceible to > error is fixes being dropped - so could we get an update of > development process end to end comparing bug-fixing versus feature > development. If too late notice, then could it be lined up for > subsequent meeting? Hi ben People must maintain their configuration. Now for external projects we do not want deadlock to move so we decided that we publish changes and that the maintainers of external projects can just merge back and continue to propose their change using configurations. Is it clearer? Stef

Sept. 27, 2016

Re: [Pharo-dev] [REMEMBER] Tech meeting rue 27/09 16UTC - We'll talk about current PharoVM ongoing development

by Ben Coman

I noticed only in a side conversation recently (rather than an announcement, did I miss something?) that the change of development process to now just submit slices to inbox and configurations get sorted later (which makes things simpler - but I wonder how configurations are then maintained. Manually would seem susceible to error is fixes being dropped - so could we get an update of development process end to end comparing bug-fixing versus feature development. If too late notice, then could it be lined up for subsequent meeting? cheers -ben On Mon, Sep 26, 2016 at 10:42 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Ah yes, I forget the âsmall detailâ of linking my channel :) > > https://www.livecoding.tv/estebanlm/ > > (I never tried, so this can fail ;) > > cheers, > Esteban > > On 26 Sep 2016, at 16:40, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hello, > > I will handle the first tech meeting tomorrow, as preview. > After several considerations, I will be trying âlivecoding.tvâ (no idea if > this is worst or better than twitchâ¦ and Iâm not very happy with the fact > that this is a âtv formatâ and not a âconversation formatâ, but well, weâll > see how it goes, maybe weâll need to review this later). > > Subject of meeting tomorrow is a general overview about current work on > PharoVM, so prepare your questions, and see you there! > > cheers, > Esteban > >

Sept. 26, 2016

Re: [Pharo-dev] FFI callout arguments - references to internal objects

by Ben Coman

Hi Esteban, Your advice lead me to make some progress. Could you have a review? http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-5-client-data-a… Its perhaps a little low level and I'd like to make CXClientData a wrapper for some of the complexity. But time to snooze now. cheers -ben On Sun, Sep 25, 2016 at 4:13 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Ben, > > I will take a better look tomorrow morning, but as first sight, seems to be that you want to declare SomeObject and receive it as argument to the callback, while you are receiving just an ExternalAddress. > If is that the problem what happens is that callbacks do not handle *any type* as the rest of UFFIâ¦ they just handle standard C types, so you will receive an ExternalAddress isnât? > You need to obtain the actual object as you need it. I see two strategies: > > 1) just create the object using SomeObject>>#fromHandle: This work fine if object is stateless and just want to access itâs defined vocabulary. > 2) orâ¦ you can just cachÃ© the data someplace and then find it using the ExternalAddress as index. > > (I hope I interpreted the problem correctlyâ¦ Iâm a bit sleep here :P) > > cheers, > Esteban > > >> On 24 Sep 2016, at 19:40, Ben Coman <btc(a)openInWorld.com> wrote: >> >> I'm seeking some support for Part 5 of my FFI tutorial >> http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-5-client-data-a… >> >> where I'm trying to replicate some C code where: >> * client_data is a void pointer, and an argument to a callout function >> * a reference to some data (an int, or a struct) is passed to the >> callout function as the client_data >> * the callout function passes that same client_data to a callback >> function which casts the client-data to the required type >> >> How can I replicate that with UFFI? The key thing is that *any* type >> can be passed via client_data. So for a normal Pharo object defined >> like... >> >> Object subclass: MyObject >> instanceVariables: 'x y' >> >> myobject := MyObject new x:3 y:4. >> >> I want to pass a reference to myobject to the callout, and in the >> callback dereference client_data to get myobject that I can operate on >> normally. >> >> Is this possible with current infrastructure, or would it need >> something new like FFIInternalPinnedReference to wrap myobject for the >> callout and unwrap it in the callback? >> >> cheers -ben >> > >

Sept. 26, 2016