October 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] GlorpSQLite Github release management

by Pierce Ng

On Sat, Oct 13, 2018 at 09:51:53AM +0800, Ben Coman wrote: > Note that git branches are simply pointers to a particular commit hash. > There is no computational link between the "branch name" in your repo > and the "branch name" in the target repo. Thanks Ben and Alistair. I'll experiment and write up whatever I find out. Pierce

Oct. 18, 2018

Re: [Pharo-users] compiling libraries for Pharo on macOS

by Pierce Ng

On Wed, Oct 17, 2018 at 10:08:58AM +0200, Michel Onoff wrote: > Specifically, I'm trying to build on all supported platforms, namely macOS, > Windows and Linux. Currently I've got Linux and Windows under control, but I > cannot find a systematic way to build on macOS. When I last tried either on Yosemite or El Capitan, I found that the Pharo at that time could not load 32/64-bit universal libraries. Building a 32-bit library for 32-bit Pharo fixed it for me. You might want to try it. Pierce

Oct. 18, 2018

Re: [Pharo-users] RBParser bug ? (Morphic corruption)

by Dimitris Chloupis

ok good to know its fixed, thanks Peter. On Wed, Oct 17, 2018 at 10:29 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Yes, this is fixed in P7 > https://pharo.fogbugz.com/f/cases/20212#BugEvent.193460 > > solution is to close your image and open again, or go to process browser > and kill the new UI loop that started. > > As a workaround you can do parseExpression:onError: (or whatever the name > is)... or I've made a small wrapper which doesn't suffer from thsi > https://github.com/peteruhnak/pharo-changes-builder > > Peter > > On Wed, Oct 17, 2018 at 5:00 PM Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> If I do something normal in the Playground like >> RBParser parseExpression: 'bac' and inspect it , it works fine >> >> If I do something like >> RBParser parseExpression: 'bac->'. Then it displays an error and things >> really get weird >> >> I get redraw problems with Morphic(if I start moving windows around), >> with windows leaving trailing images behind and Pharo slowing down. >> >> Can anyone reproduce my problem ? >> >> I can reproduce this behavior in 6.1 32 bit and 64 bit and with other >> incorrect syntax strings. >> >

Oct. 17, 2018

Re: [Pharo-users] RBParser bug ? (Morphic corruption)

by Peter Uhnak

Yes, this is fixed in P7 https://pharo.fogbugz.com/f/cases/20212#BugEvent.193460 solution is to close your image and open again, or go to process browser and kill the new UI loop that started. As a workaround you can do parseExpression:onError: (or whatever the name is)... or I've made a small wrapper which doesn't suffer from thsi https://github.com/peteruhnak/pharo-changes-builder Peter On Wed, Oct 17, 2018 at 5:00 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > If I do something normal in the Playground like > RBParser parseExpression: 'bac' and inspect it , it works fine > > If I do something like > RBParser parseExpression: 'bac->'. Then it displays an error and things > really get weird > > I get redraw problems with Morphic(if I start moving windows around), with > windows leaving trailing images behind and Pharo slowing down. > > Can anyone reproduce my problem ? > > I can reproduce this behavior in 6.1 32 bit and 64 bit and with other > incorrect syntax strings. >

Oct. 17, 2018

Re: [Pharo-users] Installing SmaCC

by Thierry Goubier

Le 17/10/2018 Ã 07:36, H. Hirzel a Ã©critÂ : > The successor of Ni is 'Spry' > > https://github.com/gokr/spry > http://sprylang.se/ > > "Spry borrows homoiconicity from Rebol and Lisp, free form syntax from > Forth and Rebol, the word of different types from Rebol, good data > structure literal support from JavaScript and the general coding > experience and style from Smalltalk. It also has a few ideas of its > own, like an interesting argument passing mechanism and a relatively > novel take on OO." > > --Hannes > > On 10/17/18, Ben Coman <btc(a)openinworld.com> wrote: >> Have you looked at Ni? (I only read about it) >> http://goran.krampe.se/2015/09/16/ni-a-strange-little-language/ Went there and ended up far more interested by Nim than by Spry ;) Thanks for the links! Thierry >> cheers -ben >> >> On Wed, 17 Oct 2018 at 03:45, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >>> Thank you Thierry , that was exactly what i was looking for :) >>> >>> On the subject of syntax, StrongTalk looks far more advanced compared to >>> what I am aiming which is basically writting C code with Smalltalk like >>> syntax. I am looking at this >>> >>> http://bracha.org/nwst.html >>> >>> Which describes some really impressive features. So I am aiming only for >>> source to source compiler and not implementation of complex systems for >>> incremental compilations , optional type system etc. >>> >>> On parsing strange code that is not much of an issue cause the project I >>> am working on has pretty reasonable code and will probably offer a way to >>> inline c code in case the parser fail. In any case my goals are small , >>> cause I dont have resources for complex implementations. Its also a >>> language that will be designed solely for my needs and be offered open >>> source for anyone else that may find it useful. In any case I am sure I >>> will have many questions to ask :) >>> >>> I was looking into ANTLR , since the book I am reading on language design >>> is using ANTLR but I rather implement this in Pharo. I used SmaCC when I >>> was working for my Python bridge and I really liked it , mostly because >>> it >>> offers ready made syntax definitions for most popular languages. Which >>> makes my life a lot easier. >>> >>> >>> On Tue, Oct 16, 2018 at 9:45 PM Thierry Goubier >>> <thierry.goubier(a)gmail.com> >>> wrote: >>> >>>> Hi Dimitris, >>>> >>>> Le 16/10/2018 Ã 19:39, Dimitris Chloupis a Ã©crit : >>>>> yes i already said that i followed the instructions in the github repo >>>> >>>> Yes, by default that installation of SmaCC does not load all parsers >>>> (some of them are fairly large). However, most of them are in the >>>> downloaded repository, so you can load them independently. >>>> >>>> Otherwise, loading that way, should load everything: >>>> >>>> Metacello new >>>> baseline: 'SmaCC'; >>>> repository: 'github://SmaCCRefactoring/SmaCC'; >>>> load: #('Tools' 'Examples' 'Examples-Extra') >>>> >>>> Regarding your language question, I'd suggest two things: >>>> >>>> - Look at StrongTalk for a way to write Smalltalk with type >>>> declarations... >>>> >>>> - C parsers able to parse most strange C code one may encounter takes >>>> some work... >>>> >>>> Regards, >>>> >>>> Thierry >>>> >>>>> On Tue, Oct 16, 2018 at 8:18 PM H. Hirzel <hannes.hirzel(a)gmail.com >>>>> <mailto:hannes.hirzel@gmail.com>> wrote: >>>>> >>>>> Refers to >>>>> https://github.com/SmaCCRefactoring/SmaCC >>>>> >>>>> which says >>>>> >>>>> This is the port for Smalltalk/Pharo 1.3, 2, 3, 4, 5 and 6. >>>>> >>>>> >>>>> Installing a Development version of Pharo for the latest Pharo >>>>> (with >>>>> no guarantees): >>>>> >>>>> Metacello new >>>>> baseline: 'SmaCC'; >>>>> repository: 'github://SmaCCRefactoring/SmaCC'; >>>>> load >>>>> >>>>> On 10/16/18, H. Hirzel <hannes.hirzel(a)gmail.com >>>>> <mailto:hannes.hirzel@gmail.com>> wrote: >>>>> > What about trying >>>>> > >>>>> > >>>>> > Metacello new >>>>> > baseline: 'SmaCC'; >>>>> > repository: 'github://ThierryGoubier/SmaCC'; >>>>> > load >>>>> > >>>>> > This worked in Pharo 6.1 in November 2017 >>>>> > >>>>> > On 10/16/18, Dimitris Chloupis <kilon.alios(a)gmail.com >>>>> <mailto:kilon.alios@gmail.com>> wrote: >>>>> >> thanks for the info Peter , will give it a try :) >>>>> >> >>>>> >> On Tue, Oct 16, 2018 at 7:35 PM PBKResearch >>>>> <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk>> >>>>> >> wrote: >>>>> >> >>>>> >>> Dimitris >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> If you download the latest Moose Suite 6.1, you will have >>>>> Pharo >>>>> 6.1 with >>>>> >>> lots of extra packages, including SmaCC. The SmaCC includes >>>>> compilers >>>>> >>> for >>>>> >>> C, Smalltalk and Java, among others, but with little or no >>>>> >>> documentation. >>>>> >>> I >>>>> >>> am not a SmaCC expert, so I canât say whether it will do what >>>>> you want, >>>>> >>> but >>>>> >>> at least it will give you a start. Moose also includes >>>>> PetitParser and >>>>> >>> PP2,if you want to try other parsing approaches. Of course, >>>>> the >>>>> Windows >>>>> >>> version is 32-bit only, for reasons explained elsewhere in >>>>> this >>>>> thread. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> HTH >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Peter Kenny >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> *From:* Pharo-users <pharo-users-bounces(a)lists.pharo.org >>>>> <mailto:pharo-users-bounces@lists.pharo.org>> *On Behalf Of >>>>> >>> *Dimitris >>>>> >>> Chloupis >>>>> >>> *Sent:* 16 October 2018 15:40 >>>>> >>> *To:* Any question about pharo is welcome >>>>> <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> >>>>> >>> *Subject:* [Pharo-users] Installing SmaCC >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Hey guys >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> I downloaded the latest Pharo 6.1 64bit for Windows and tried >>>>> to install >>>>> >>> SmaCC through the catalog browser but it failed >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> I did manage to install it following the instruction in the >>>>> github repo >>>>> >>> but I see that I am missing most parser packages. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> The languages I am interested are Smalltalk (which is >>>>> included) >>>>> and C >>>>> >>> (if >>>>> >>> possible C++ too) cause I will be creating a new language >>>>> which >>>>> will be >>>>> >>> a >>>>> >>> cross between C and Smalltalk (very similar to smalltalk >>>>> syntax >>>>> but with >>>>> >>> the addtion of C types and no GC and dynamic typing and also >>>>> a >>>>> partial >>>>> >>> implementation of OOP that is quite diffirent). My goal is >>>>> compilation >>>>> >>> of >>>>> >>> my language to readable C code so the ability to parse also >>>>> existing C >>>>> >>> code >>>>> >>> is needed. >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Any help is greatly appreciated , thanks :) >>>>> >>> >>>>> >> >>>>> > >>>>> >>>> >>>> >>>> >> > >

Oct. 17, 2018

RBParser bug ? (Morphic corruption)

by Dimitris Chloupis

If I do something normal in the Playground like RBParser parseExpression: 'bac' and inspect it , it works fine If I do something like RBParser parseExpression: 'bac->'. Then it displays an error and things really get weird I get redraw problems with Morphic(if I start moving windows around), with windows leaving trailing images behind and Pharo slowing down. Can anyone reproduce my problem ? I can reproduce this behavior in 6.1 32 bit and 64 bit and with other incorrect syntax strings.

Oct. 17, 2018

Re: [Pharo-users] Dictionary and Date as keys

by Sven Van Caekenberghe

Chris, That is not what I am seeing in Pharo 7: date1 := Date today. date2 := Date today translateToUTC. date1 = date2. "false" date1 hash = date2 hash. "false" dictionary := Dictionary new. dictionary at: date1 put: date1. dictionary at: date2 put: date2. (dictionary at: date1) = date1. "true" (dictionary at: date2) = date2. "true" dictionary. "a Dictionary(17 October 2018->17 October 2018 17 October 2018->17 October 2018 )" date1 offset. "0:02:00:00" date2 offset. "0:00:00:00" Both dates are different, but they are equal (an operation that ignores the offsets) date1 equals: date2. "true" Sven > On 17 Oct 2018, at 16:33, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > > Hi, > > On Tue, Oct 16, 2018 at 1:28 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Petr, > > On Tue, 16 Oct 2018 at 21:25, Petr Fischer via Pharo-users > <pharo-users(a)lists.pharo.org> wrote: > > > > My problem - use Dates as Dictionary keys - shortly: > > > > d1 := Date today translateToUTC. > > d2 := Date today. > > > > d1 = d2. (true!) > > Of course, this doesn't help with using Date as a key in a dictionary. > Probably your best option is to look at Sven's excellent ZTimezone > package (although I haven't tested it in this scenario). > > The base problem here is that the hash of the dates is not the same for dates that are equal - that should never happen. If you try > d1 hash = d2 hash > you should see that the hash's are different (Petr for sure; you for the cases where the offsets are different). > > When objects (especially fo the same class) are =, then their hash must be the same as well, or things break. > > -cbc

Oct. 17, 2018

Re: [Pharo-users] Dictionary and Date as keys

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote >> the obvious way to introduce it would >> have been to introduce a new DateInZone class. Yes, that would have been nice. Especially since IMHO this is the more common, simple case, and least surprising to new users. I would assume by the time you're building international apps there is decent familiarization with the system. Sven Van Caekenberghe-2 wrote > Both the simple, abstract calendar date as well as the more complex date > in a timezone with a concrete timespan are useful. Agreed. The additional problem (besides incompatible/inconsistent naming) with the Squeak/Pharo implementation of option #2 is that they are buggy and incomplete. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 17, 2018

Re: [Pharo-users] Dictionary and Date as keys

by Chris Cunningham

Hi, On Tue, Oct 16, 2018 at 1:28 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Petr, > > On Tue, 16 Oct 2018 at 21:25, Petr Fischer via Pharo-users > <pharo-users(a)lists.pharo.org> wrote: > > > > My problem - use Dates as Dictionary keys - shortly: > > > > d1 := Date today translateToUTC. > > d2 := Date today. > > > > d1 = d2. (true!) > > Of course, this doesn't help with using Date as a key in a dictionary. > Probably your best option is to look at Sven's excellent ZTimezone > package (although I haven't tested it in this scenario). > The base problem here is that the hash of the dates is not the same for dates that are equal - that should never happen. If you try d1 hash = d2 hash you should see that the hash's are different (Petr for sure; you for the cases where the offsets are different). When objects (especially fo the same class) are =, then their hash must be the same as well, or things break. -cbc

Oct. 17, 2018

Re: [Pharo-users] compiling libraries for Pharo on macOS

by Michel Onoff

Ben, thanks for the references. On 2018-10-17 13:57, Ben Coman wrote: > On Wed, 17 Oct 2018 at 18:33, Michel Onoff <michel.onoff(a)web.de > <mailto:michel.onoff@web.de>> wrote: > > Afaik, dlopen(3), which I presume UFFI uses internally to load (shared) > libraries on demand (I cannot imagine anything else), looks in > LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on macOS), not in PATH. > > What is the strategy that UFFI internally uses in its own > implementation > to search for a library? What if that library depends on other > libraries > in turn? Where would these ones be searched for? > > > I'm not really familiar with the mechanism, but a quick trawl of the VM > sources found these... > [1] > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/v… > [2] > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/Mac%20… > [3] > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/iOS/vm… > [4] > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/iOS/vm… > > For [1] and [2],Â ioLoadModule() seems to use LD_LIBRARY_PATH, > but [3] and [4] don't. > > IIUC, [2] is a deprecated version and [3] is the one you are concerned > about. > > btw, If you want to discuss those files, consider cross posting to vm-dev. > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > > cheers -ben

Oct. 17, 2018