- Pharo-dev - lists.pharo.org

Recommended production VM on latest macOS Sierra?

by Bernhard Pieber

Hi, What VM would you recommend for a production app on macOS Sierra? - Pharo 6, right? - I assume 32-bit because 64-bit is still experimental, right? - The one I get with âcurl get.pharo.org | bashâ has a reproducible crash when typing (https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141) So it canât be the recommended one, right? I must admit I am quite confused. Cheers, Bernhard

July 3, 2017

Re: [Pharo-dev] Reflecting on data (literal) object syntax

by Ben Coman

Thanks Christian for the open release of pdf4smalltalk. Sorry I aborted the two times I started to port it to Pharo. The task of dealing with both file format and namespace differences to synchronise with VW was too big for me. Now with Iceberg, if VisualWorks might work with git that would knock down one barrier and I might have another go. On Mon, Jul 3, 2017 at 5:45 PM, Christian Haider < christian.haider(a)smalltalked-visuals.com> wrote: > I did > > > > *Von:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *Im Auftrag > von *Serge Stinckwich > *Gesendet:* Montag, 3. Juli 2017 11:40 > *An:* Pharo Development List <pharo-dev(a)lists.pharo.org> > > *Betreff:* Re: [Pharo-dev] Reflecting on data (literal) object syntax > > > > Hi Christian, > > > > interesting ! Maybe you can release your software with an MIT licence ? > > > > Regards, > > > > On Mon, Jul 3, 2017 at 10:06 AM, Christian Haider < > christian.haider(a)smalltalked-visuals.com> wrote: > > I solved this with Values[1] for VW and I am very happy with it (using it > intensively/routinely). > > Your example would look like: > > > > (PointCollection points: (Array > > with: (Point x: 10 y: 20) > > with: (Point x: 5 y: 8) > > )) > > And I remember you saying pdf4smalltalk relied heavily on this, so having Values integrated (if it was broadly useful) would also be a minor step in porting pdf4smalltalk to Pharo. cheers -ben > > > As you see, it is the same except that lots of noise is gone. > > Drawbacks: only literal objects (like Values) are allowed; i.e. no cyclic > structures (same with JSON etc.) > > and the order of arguments is fixed unlike JSON (but you can add > constructors for every permutation J). > > > > I think this is very clear and direct (no magic from parsers etc.). I like > it most for configurations (see everything at a glance) and interface data. > > > > Best, > > Christian > > > > [1] https://wiki.pdftalk.de/doku.php?id=complexvalues > > > > *Von:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *Im Auftrag > von *Norbert Hartl > *Gesendet:* Montag, 3. Juli 2017 10:28 > *An:* Pharo Dev <pharo-dev(a)lists.pharo.org> > *Betreff:* Re: [Pharo-dev] Reflecting on data (literal) object syntax > > > > Eliot, > > > > Am 01.07.2017 um 20:22 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > Hi Norbert, > > > On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > But what is DataFrame? > > > the new collection done by alesnedr from Lviv. It is really nice but > does not solve the problem of the compact syntax. > > > STON fromString: 'Point[10,20]' > > Same goes for JSON. > > We were brainstorming with marcus and we could have a first nice extension: > > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > > 10@20 > > > Now in addition I think that there is a value in having an object > literal syntax. > > I pasted the old mail of igor on object literals because I like the > idea since it does not add any change in the parser. > Do you remember what were the problem raised by this solution (beside > the fact that it had too many # and the order was like in ston not > explicit). > > I would love to have another pass on the idea of Igor. > > > What I don't like about it is that the object literal exposes the internal > implementation of the object. Everything is based on index. So it could > suffer the same problem as fuel. When you don't have the exact same code > the deserialization fails. > > > Indeed this is why > { 'x' -> 10 .'y' -> 20 } asObjectOf: #Point. > could be more robust. > We could extend the object literal syntax to use association for non > collection. > > I think it is more robust and more explicit. I do not know what are the > semantics of detecting something as #Point being a class name. Is it then > forbidden to use symbols with uppercase letters? I think something like > > { #x -> 10 . #y -> 20} asObjectOf: #Point > > is handling the format with implicit knowledge of type. While the explicit > version would be > > { #Point -> { #x -> 10 . #y -> 20}} asObject > > And then nested objects are as easy as > > {#PointCollection -> { > #points -> { {#Point -> { #x -> 10 . #y -> 20} }. > {#Point -> { #x -> 5 . #y -> 8} } } } asObject > > > The -> messages are just noise and add additional processing for nothing. > This is just as effective: > > { #Point. { #x. 10 . #y. 20}} asObject > > {#PointCollection. { #points. { {#Point. { #x. 10 . #y. 20} }. > {#Point. { #x. 5 . #y. 8} } } } asObject > > So an object is a pair of a class name and an array of slot specifier > pairs, and a slot specifier is a pair of a slot band and a value. And of > course that means that many object specs can be literal, which is useful > for storing in pragmas etc: > > #(PointCollection > (points ((Point (x 10 y 20)) > ((Point (x 5 y 8)))) asObject > > Agreed. My first impression was it should be something like S-expression > which your example is. I was misled by the idea it should be closer to the > programming syntax. But a parser does not care if implemented properly, > that's right. I like the compactness of that format but still find it a bit > hard to read if there is only pairs. As this object literal syntax is meant > to be written in code it is important that it reads well even if there are > noisy characters. > > > would give a PointCollection of two point objects. My future wish would be > that there is an object literal parser that takes all of the information > from the format. And then a object literal parser that is aware of slot > information. Meaning that the type information can be gathered from the > object class instead having it to write in the format. In the > PointCollection the slot for points would have the type information #Point > attached. The format goes then to > > { #points -> { > { #x -> 10 . #y -> 20 }. > { #x -> 5 . #y -> 8 } } > > which would then the equivalent to something like JSON > > { "points" : [ > { "x" : 10, "y" : 20 }, > { "x" : 5, "y" : 8 } ] } > > What I don't know is how to solve the difference between a dictionary and > an collection of associations. > > > That's incidental to the format, internal to the parser. If the parser > chooses to build a dictionary as it parses so be it. The point is that the > output is as you specify; a tree of objects. > > The thing to think about is how to introduce labels so that sub objects > can be shared in the graph, the naÃ¯ve deepCopy vs deepCopyUsing: issue. > > > > I'm not sure this is necessary. It should be a format to easily > instantiate a small tree of objects. Making it build a graph instead of a > tree makes everything much more complicated. Either we decide that STON can > do the full set and in that case it is probably less valuable to have a > simple syntax to write in code. Or we need to break pairs rule. In that > case an object definition can have an optional third argument which would > be the label for the object. The draback is that the label needs to be > before the array of slots > > > > { :v1 #ValueHolder { 'contents' . { ValueHolder . { 'contents' . @v1 }}}} > > > > Or something like this. It would be in theory closer to STON using the @ > reference. The difference is that STON has indexed object access and that > variant would make it based on labels.Or something like this. > > > > Norbert > > > > > > > Norbert > > > > As a dictionary is both, an array of associations and a key-value store, > it works perfectly there. But for other objects I have doubts. Especially > is in a lot of contexts you need to have a mapping of internal state to > external representation. It can be applied afterwards but I'm not sure that > can work all the time. > > > Yes after we should focus on the frequent cases. And may be having a > literal syntax for dictionary would be good enough. > > I will do another version of igor's proposal with associations to see > how it feels. > > > my 2 cents, > > Norbert > > > Stef > > > > > ---------- Forwarded message ---------- > From: Igor Stasenko <siguctua(a)gmail.com> > Date: Fri, Oct 19, 2012 at 1:09 PM > Subject: [Pharo-project] Yet another Notation format: Object literals > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > > > Hi, > as i promised before, here the simple smalltalk-based literal format. > It based on smalltalk syntax, and so, unlike JSON, it doesn't needs to > have separate parser (a normal smalltalk parser used for that). > > The idea is quite simple: > you can tell any object to represent itself as an 'object literal' , > for example: > > (1@3) asObjectLiteral > --> #(#Point 1 3) > > { 1@2. 3@4. true. false . nil } asObjectLiteral > > -> #(#Array #(#Point 1 2) #(#Point 3 4) true false nil) > > (Dictionary newFromPairs: { 1->#(1 2 3) . 'foo' -> 'bar' }) asObjectLiteral > -> > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') > > Next thing, you can 'pretty-print' it (kinda): > > #(#Dictionary 1 #(#Array 1 2 3) 'foo' 'bar') printObjectLiteral > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' > > > and sure thing, you can do reverse conversion: > > '#(#Dictionary > 1 > (#Array 1 2 3) > ''foo'' ''bar'')' parseAsObjectLiteral > > a Dictionary('foo'->'bar' 1->#(1 2 3) ) > > Initially, i thought that it could be generic (by implementing default > Object>>#asObjectLiteral), > but then after discussing it with others, we decided to leave > > Object>>#asObjectLiteral to be a subclass responsibility. > So, potentially the format allows to represent any object(s) as > literals, except from circular referencing objects, of course. > > The implementation is fairly simple, as you may guess and contains no > new classes, but just extension methods here and there. > > Take it with grain and salt, since it is just a small proof of > concept. (And if doing it for real it may need some changes etc). > Since i am far from areas right now, where it can be used, i don't > want to pursue it further or advocate if this is the right way to do > things. > Neither i having a public repository for this project.. > > So, if there anyone who willing to pick it up and pursue the idea > further, please feel free to do so and make a public repository for > project. > > > > > > > > -- > > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

July 3, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 26 June 2017

by Ben Coman

On Mon, Jul 3, 2017 at 2:00 PM, <estebanlm(a)gmail.com> wrote: > Hello! > > This is my weekly ChangeLog, from 26 June 2017 to 2 July 2017. > You can see it in a better format by going here: > http://log.smallworks.eu/web/search?from=26/6/2017&to=2/7/2017 > > ChangeLog > ========= > > 29 June 2017: > ------------- > > * ... and I spent some time figuring out why windows users have a > persistent error about access files. > > We should always remember the windows path limitations (256) :) > > Now, the workaround for this is to execute this in command line: > > ---- > git config --system core.longpaths true > ---- > > but of course, this is just a workaround because people using Iceberg > could not hava installed a > command line git client. I will need to check in the future this :( > Nice pickup. I notice this command creates the file /etc/gitconfig like this... [core] longpaths = true and instead using --local update $ cp .git/config /tmp/oldconfig $ git config --local core.longpaths true $ diff .git/config /tmp/oldconfig 6d5 < longpaths = true Sorry I don't have time to test further, but if --local has the same positive effect per repo as --global, could Pharo modify the config text file directly? > > * I spent some time trying to get [Iceberg version dev-0.5]( > https://github.com/pharo-vcs/iceberg/tree/dev-0.5) > to load properly (yesterday's script is not working). > > The reason is that +Metacello+ fails to upgrade packages from a > baseline. And there is no way (at least > that I found) to force the upload. > > So this is the updated script to test dev-0.5: > > 1. Download latest vm and image. > > ---- > wget -O- get.pharo.org/64/70+vmLatest | bash > wget -O- get.pharo.org/64/70+vmTLatest | bash # for linux systems > ---- > > 2. Execute this on your image > > ---- > #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' > 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' > 'LibGit-Core' 'BaselineOfLibGit') > do: [ :each | each asPackage removeFromSystem ]. > > Metacello new > baseline: 'Iceberg'; > repository: 'github://pharo-vcs/iceberg:dev-0.5'; > load. > ---- > > This should actually remove old iceberg version then install new one. > > > 28 June 2017: > ------------- > > * Ok, I get the VM to compile correctly with the new libgit2 version, > and now +latest vm+ comes with > +libgit 0.25.1+ for both 32 and 64 bits versions. > > I also made some minor fixes to +iceberg dev-0.5+ and it should be > ready to test and release. This > version incorporates some important changes that will allow us to work > with it to make changes to > Pharo itself (and that will be noticed on big projects): > > * it has cherry-pick. > * it speeds up sincronization by introducing more precise comparisons > instead making a "full scan" > sincronization = something naughty you do at regular intervals ?? %^) > * it keeps in sync branch on disk and branch on iceberg (before it was > keeping them separately and it was very confusing) > > To test it, you can execute: > > ---- > wget -O- get.files.org/64/70+vmLatest | bash > wget -O- get.files.org/64/70+vmTLatest | bash # on linux systems > ---- > > then you will need to load version +dev-0.5+ : > > ---- > Metacello new > baseline: 'Iceberg'; > repository: 'github://pharo-vcs/iceberg:dev-0.5'; > load. > "And you will need to execute this... I will need to update the > baseline with this, > now that I think :)" > LGitExternalStructure allSubclassesDo: #compileFields. > ---- > > * I finished ensuring [iceberg](https://github.com/ > pharo-vcs/iceberg/tree/dev-0.5) will work on 64 bits. > > Now, I needed to make some fixes for UFFI, which I put in [case: > 20198](https://pharo.fogbugz.com/f/cases/20198) (it is imperative to > include > this to be able to backport 0.5 into Pharo 6.0). Also, I will need to > promote a new VM as stable. > > I'm not sure I want to backport this into Pharo 6. I know I promised > but complications are... more than > benefits, I think: You will need a new VM. People will not know that > and they will download a P6 image > with the older VM and this will cause problems. > > Maybe is better to move all this to P7? > > > cheers! > Esteban > >

July 3, 2017

Re: [Pharo-dev] [Vm-dev] multiple crashes on macOS Sierra

by Bernhard Pieber

Hi, Using Aliaksei Syrelâs instructions I can reproduce the crash on macOS Sierra Version 10.12.5 using the Pharo 6. I installed it using: curl get.pharo.org | bash How can I get the latest VM for Pharo 6? âcurl get.pharo.org/vmLatest60 | bashâ did not work for me. [1] Cheer, Bernhard [1] MacBookProRetina:pharo-vm-test bernhard$ curl get.pharo.org/vmLatest60 | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 5696 100 5696 0 0 48223 0 --:--:-- --:--:-- --:--:-- 48271 Downloading the latest pharoVM: http://files.pharo.org/get-files/60/pharo-mac-latest.zip [pharo-vm/vm.zip] End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of pharo-vm/vm.zip or pharo-vm/vm.zip.zip, and cannot find pharo-vm/vm.zip.ZIP, period. > Am 01.06.2017 um 23:00 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > >> On Jun 1, 2017, at 7:23 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> What is in bintray now is the same as vm latest :) > > Do I understand correctly that: > curl get.pharo.org/vmLatest60 | bash > > will get the VM with the fix? > > Doru > > >> On 1 Jun 2017, at 18:30, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> Tobias has commited a fix in cog branch a few days ago. >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f07ffbedcc184391e… >>> So could you try latest Vm from bintray and report? >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0f07ffbedcc184391e… >>> >>> >>> 2017-06-01 16:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>> I am not sure what is the status with this issue, but it seems clear that there exists a problem, so I opened an issue to accumulate the different opinions: >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 >>> >>> Cheers, >>> Doru >>> >>> >>> >>>> On May 29, 2017, at 9:53 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Tobias Pape <Das.Linux(a)gmx.de> >>>> Date: Mon, May 29, 2017 at 12:09 AM >>>> Subject: Re: [Vm-dev] multiple crashes on macOS Sierra >>>> To: John McIntosh <johnmci(a)smalltalkconsulting.com> >>>> Cc: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> >>>> >>>> >>>> >>>> Hi John, all >>>> >>>> >>>>> On 28.05.2017, at 22:12, John McIntosh <johnmci(a)smalltalkconsulting.com> wrote: >>>>> >>>>> At commit point d0e7bfa0f8d99b856d9ac56372f7dacecdd63106 (5/5/17) Tobias added >>>>> >>>>> >>>>> NSEvent* syntheticEvent = AUTORELEASEOBJ([NSEvent keyEventWithType:(isUp ? NSEventTypeKeyUp : NSEventTypeKeyDown) >>>>> location:[theEvent locationInWindow] >>>>> modifierFlags:(isUp ? oldFlags : [theEvent modifierFlags]) >>>>> timestamp:[theEvent timestamp] >>>>> windowNumber:[theEvent windowNumber] >>>>> context:nil >>>>> characters:@"" >>>>> charactersIgnoringModifiers:@"" >>>>> isARepeat:NO >>>>> keyCode:[theEvent keyCode]]); >>>>> >>>>> in sqSqueakOSXOpenGLView.m at - (void)flagsChanged:(NSEvent *)theEvent >>>> >>>> That's correct. >>>> >>>>> >>>>> However I believe this is incorrect as the NSEvent class side method is by the old non-arc memory rules implicitly an autoreleased object, so doing the AUTORELEASEOBJ() might cause side effects. https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/… >>>>> >>>>> + (NSEvent *)keyEventWithType:(NSEventType)type location:(NSPoint)location modifierFlags:(NSEventModifierFlags)flags timestamp:(NSTimeInterval)time windowNumber:(NSInteger)wNum context:(NSGraphicsContext *)unusedPassNil characters:(NSString *)keys charactersIgnoringModifiers:(NSString *)ukeys isARepeat:(BOOL)flag keyCode:(unsigned short)code; >>>> >>>> Well, I have not found a reference to how this relates to autorelease (the Apple docs are becoming increasingly useless these days :() >>>> I read this https://developer.apple.com/reference/appkit/nsevent/1533943-keyeventwithty… >>>> and the header /System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h and although autorelase pops up somewhere in the file, it does not somewhere near the declaration. >>>> I read through the code an found quite a few AUTORELEASEOBJ() around object creation and (apparently wrongly) thought I would need that here. >>>> >>>> >>>> I now understand that I should only autorelease alloc/inited stuff. >>>> >>>> So you may be right here. >>>> >>>> Fixed in 0f07ffbed >>>> >>>> Best regards >>>> -Tobias >>>> >>>>> >>>>> If Tobias can verify and submit a change we can see if that affects the behaviour we have been observing. Note that I"ve not been able to recreate the problem, but in eyeballing the code this leaps out as suspect. >>>> >>>> [snip] >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >>> > > -- > www.tudorgirba.com > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut."

July 3, 2017

Re: [Pharo-dev] Pharo Launcher

by Ben Coman

On Mon, Jul 3, 2017 at 6:35 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com > wrote: > > > On Thu, Jun 29, 2017 at 2:32 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi >> >> where can I find the pharo launcher for the latest version of Pharo? >> >> > > âI'm still fighting to use Pharo Launcher in Cameroon with very low > bandwidth ... > Most of the time I have an error: can't find EOCD position. > What is the meaning of this error ? a latency problem ? > http://forum.world.st/quot-error-can-t-find-EOCD-position-quot-during-updat… >> My screen shows I'm processing "update-nice.42.mcm" >> and downloading "kernel-nice.278.mcz" >> and I get a debugger notify "can't find EOCD position" >> >> Known? Or does someone want some debugging data? >Clean out the MC cache and try again. This error means the zip is >corrupt. With very low bandwidth, maybe you want to limit totally clearing the cache. You might try a script that copies the .mcz to .zip and uses the system `unzip` to identify corrupt files. cheers -ben

July 3, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.5 released

by Norbert Hartl

> Am 03.07.2017 um 14:45 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > >> On 3 Jul 2017, at 13:32, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> So it is decided there won't be an official pharo6 supporting iceberg? > > not today :) > I will release Pharo 6.1 with updated icebergâ¦ because it requires a new VM and I donât want to break current downloaded version. > Problem is: once we jump to 6.1, 6.0 will not be maintained anymoreâ¦ not cool, maybe. But inevitable due the amount of effort we can put there. > Ok, understood! And glad we will have 6.1. Great! Norbert > Esteban > >> >> Norbert >> >>> Am 03.07.2017 um 13:28 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>> >>>> >>>> On 3 Jul 2017, at 13:18, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>> >>>> Hi all, >>>> Iâm releasing 0.5 version of iceberg. >>>> This is the changelog: >>>> >>>> Major changes: >>>> ---- >>>> - works on 64bits >>>> - adds cheery-pick >>>> >>>> Other: >>>> ---- >>>> This version also includes a list of fixes, most important one is this: >>>> >>>> - branchs are kept inline with local working copy (so if you change a branch in command line or in another image it will indicate it correctly) >>>> >>>> But there are many others, next version will have a full list, I promise :) >>>> >>>> Now, to actually use it you will need to accomplish several steps (until I update the image) >>>> >>>> 1) You need to download the new stable VM for P7 (it does not matters if you are on P6). >>>> Zeroconf: >>>> >>>> 64bits: >>>> wget -O- get.pharo.org/64/vm70 <http://get.pharo.org/vm70> | bash >>>> wget -O- get.pharo.org/ <http://get.pharo.org/vm70>64/ <http://get.pharo.org/vm70>vmT70 <http://get.pharo.org/vm70> | bash #If you are on linux >>>> >>>> 32bits: >>>> wget -O- get.pharo.org/vm70 <http://get.pharo.org/vm70> | bash >>>> wget -O- get.pharo.org/vmT70 <http://get.pharo.org/vm70> | bash #If you are on linux >>>> >>>> then, to update, execute this (sorry, this is like that because we have still an older Metacello version): >>>> >>>> #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core' 'BaselineOfLibGitâ) >>>> do: [ :each | each asPackage removeFromSystem ]. >>>> >>>> Metacello new >>>> baseline: 'Iceberg'; >>>> repository: 'github://pharo-vcs/iceberg <github://pharo-vcs/iceberg>'; >>>> load. >>> >>> Maybe I was not clearâ¦ this script works also for P6 (*if * you have the new VM) :) >>> >>>> >>>> cheers! >>>> Esteban >> >

July 3, 2017

Re: [Pharo-dev] The new implementation of current working directory

by Alistair Grant

Hi Rajula, On Thu, Jun 29, 2017 at 05:42:02AM -0700, Rajula Vineet wrote: > Hi all, > > As I have already been posting about my GSoC work and updates on my blog > <https://vineetreddy.wordpress.com> and on the mailing list > <http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12947…> > . In this post, I would like to go in depth of my work on 'the working > directory' so that I can get valuable feedback and suggestions from > everyone. This discussion was started on an github PR > <https://github.com/pharo-project/pharo/pull/96> which was conflicting my > PR. It looks like my concerns were unfounded, but many thanks for taking the trouble to follow up on this. It would good if you could keep a similar caching strategy to the one I introduced as the performance gains can be significant (as suggested by Cyril's comment). Thanks again, Alistair > Firstly, I would like to go through the current implementation of the > working directory. With this implementation, when you use the > defaultWorkingDirectory method, the directory in which the running image is > present in, is returned. This is not a completely good working because when > you run the image from a different directory like './pharo ../Pharo.image' > the working directory is the one in which your image resides. But that isn`t > your actual working directory. Due to this, > > 1. Pharo cannot be installed as a normal application in a read-only > environment. > 2. Pharo wrongly reads and writes files relative to the 'working directory'. > 3. It also makes scripting difficult. > > In the FogBugz issue here > <https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory> , there > is an example which explains the problem. > > Let say the Pharo VM and Image are in the directory "~/Pharo", > and I wrote a script in "~/Documents/Pharo-scripts" called > "perfect-numbers.st" > > I have 2 possibilities: > > cd ~/Pharo && pharo Pharo.image st > ~/Documents/Pharo-scripts/perfect-numbers.st // works > > or > > cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st > perfect-numbers.st // doesn't work... > > It doesn't work because when pharo wants to load the file, > it tries to locate it with: FileSystem disk workingDirectory !!! > which is NOT the current working directory." > > I hope you get the problem. > > So for the new implementation <https://github.com/rajula96reddy/pharo-cli> > with the help of Guille I researched about $PWD and getcwd() for a while and > wrote a new implementation. This is how it goes > 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and > 'getPwdFromFFIwithsize:'. These call the getcwd() function using the UFFI > 2. And a new method currentWorkingDirectoryPath and > currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the > above method and gets the working directory. > 3. To integrate this, I have patched the DiskStore method > 'defaultWorkingDirectory' to use the new methods in OSPlatform. > > I have checked all the sendors of the 'defaultWorkingDirectory' for any > issue. And I also wrote some unit tests. So, the new implementation is > working fine. With this, now I am able to get the right working directory. > The example mentioned above works perfectly. > > But, there may be a few cases where it can break interoperability between > Pharo and other Smalltalk dialects like squeak etc. And the 'pharo-local' > directory and its methods should also be patched subsequently. In fact, > these problems can be tackled by running image from its own directory itself > (which is obvious ;) ) or by using the method imageDirectory in FileLocator > class explicitly when necessary. But overall a good thing is this is will > ensure the system will behave as in other languages. > > I have completed this implementation and submitted a PR > <https://github.com/pharo-project/pharo/pull/92> to github. But because of > some dependency issue, it has not yet been merged. With the help of my > mentor, I am working on the problem. > > Thanks for reading all this. Please give your feedback and comments on this > new implementation. Your suggestions help me in learning more about the > project and also about the organization. > > Thanks, > Rajula > > > > -- > View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-t… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

July 3, 2017

Re: [Pharo-dev] [ANN] New stable VM for P7

by Esteban Lorenzano

I cannot reproduce it. Anyway, yesâ¦ the purpose of this new stable VM (for P7â¦ for P6 is still the same) is to have a new version of libgit2 + some fixesâ¦ but is not guaranteed it will fix that :( Esteban > On 3 Jul 2017, at 13:45, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi Esteban, > > Thanks for pushing it forward! :) > > Unfortunately there is still The Typing Crash Bug. But now I found a way how to 100% reproduce it: > > 1) Open any text editor (Playground) > 2) Hold "s" button so it starts typing many "s" in playground. Press for ca. 3-4 seconds. > 3) Release "s" button > 4) Press left arrow > 5) .... > 6) crash! > > Here is a video of two consecutive crashes: > â > Â PharoStable-TypingCrash.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTV1R3SlRlY0lkZVk/view?usp=drive…>â > Cheers, > Alex > > On 3 July 2017 at 13:02, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hi all, > > I declared a new stable VM for Pharo 7. > This VM includes a new version of libgit2 and because of that *it cannot be used on Pharo 6 (if you are using Iceberg)* > > Just that :) > > cheers! > Esteban >

July 3, 2017

Re: [Pharo-dev] [ANN] Iceberg 0.5 released

by Esteban Lorenzano

> On 3 Jul 2017, at 13:32, Norbert Hartl <norbert(a)hartl.name> wrote: > > So it is decided there won't be an official pharo6 supporting iceberg? not today :) I will release Pharo 6.1 with updated icebergâ¦ because it requires a new VM and I donât want to break current downloaded version. Problem is: once we jump to 6.1, 6.0 will not be maintained anymoreâ¦ not cool, maybe. But inevitable due the amount of effort we can put there. Esteban > > Norbert > >> Am 03.07.2017 um 13:28 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >>> >>> On 3 Jul 2017, at 13:18, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> Hi all, >>> Iâm releasing 0.5 version of iceberg. >>> This is the changelog: >>> >>> Major changes: >>> ---- >>> - works on 64bits >>> - adds cheery-pick >>> >>> Other: >>> ---- >>> This version also includes a list of fixes, most important one is this: >>> >>> - branchs are kept inline with local working copy (so if you change a branch in command line or in another image it will indicate it correctly) >>> >>> But there are many others, next version will have a full list, I promise :) >>> >>> Now, to actually use it you will need to accomplish several steps (until I update the image) >>> >>> 1) You need to download the new stable VM for P7 (it does not matters if you are on P6). >>> Zeroconf: >>> >>> 64bits: >>> wget -O- get.pharo.org/64/vm70 <http://get.pharo.org/vm70> | bash >>> wget -O- get.pharo.org/ <http://get.pharo.org/vm70>64/ <http://get.pharo.org/vm70>vmT70 <http://get.pharo.org/vm70> | bash #If you are on linux >>> >>> 32bits: >>> wget -O- get.pharo.org/vm70 <http://get.pharo.org/vm70> | bash >>> wget -O- get.pharo.org/vmT70 <http://get.pharo.org/vm70> | bash #If you are on linux >>> >>> then, to update, execute this (sorry, this is like that because we have still an older Metacello version): >>> >>> #('Iceberg-UI' 'Iceberg-Plugin' 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core' 'BaselineOfLibGitâ) >>> do: [ :each | each asPackage removeFromSystem ]. >>> >>> Metacello new >>> baseline: 'Iceberg'; >>> repository: 'github://pharo-vcs/iceberg <github://pharo-vcs/iceberg>'; >>> load. >> >> Maybe I was not clearâ¦ this script works also for P6 (*if * you have the new VM) :) >> >>> >>> cheers! >>> Esteban >

July 3, 2017

[ANN] for P7, default VM for linux moved to threaded

by Esteban Lorenzano

Hi, I made default vm for linux (for P7) the default VM. I also updated zeroconf to add a new type of download for linux: the explicit iTimer heartbeat download. So, for P7, if you download the default stable VMâ¦ it will be a threaded VM. Take that into account :) Esteban

July 3, 2017