July 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reflecting on data (literal) object syntax - porting PDF
by Christian Haider July 4, 2017

July 4, 2017

Hi Ben, at ESUG I will hopefully show the new version of the library with a new PDF type implementation which allows the classes to be freely (re)named. This should make a port a lot easier. Currently I am working on the port for Gemstone. If that works, it could be more than half the way towards a Pharo/Squeak version. cheers Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Ben Coman Gesendet: Montag, 3. Juli 2017 18:54 An: Pharo Development List <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] Reflecting on data (literal) object syntax 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 <mailto:christian.haider@smalltalked-visuals.com> > wrote: I did Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <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 <mailto:pharo-dev@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 <mailto:christian.haider@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 :)). 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 <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 <mailto:pharo-dev@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 <mailto:eliot.miranda@gmail.com> >: Hi Norbert, On Jul 1, 2017, at 7:36 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> > wrote: Am 30.06.2017 um 21:14 schrieb Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@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 <mailto:siguctua@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 <mailto:Pharo-project@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/

1 0

Esteban's ChangeLog week of 26 June 2017
by estebanlm＠gmail.com July 3, 2017

July 3, 2017

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 :( * 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" * 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

2 1

Fwd: [Vm-dev] multiple crashes on macOS Sierra
by Eliot Miranda July 3, 2017

July 3, 2017

---------- 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/MemoryMgmt/ Articles/mmRules.html > > + (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-keyeventwithtype?language=objc 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]

5 5

[ANN] New stable VM for P7
by Esteban Lorenzano July 3, 2017

July 3, 2017

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

2 2

git, packages, and package dependencies (also migration from sthub to git)
by Peter Uhnak July 3, 2017

July 3, 2017

Hi, after many-o-hours spent on my git-migration tool ( https://github.com/peteruhnak/git-migration ), I've concluded that the migration cannot be properly done for packages. In mcz/monticello, every package has an independent history and can change independently of each other. In git, this history is merged into a single hierarchy, therefore: * a specific version of package A mandates specific versions of every other package in the project * it is not possible to do a 1:1 migration from mcz to git and keep this flexibility Both ways (mcz and git) have advantages and disadvantages of their own, however as far as I could tell, they are incompatible; so mcz flexibility and some information (history) will be lost during migration. The only solution I see is to either separate every package to a separate git project to keep the flexibility or use git subtree/git module... which are both complications... As a git commit specifies the code in the entire project, even across packages, then I wonder what is the point of expressing package dependencies _within_ the project (whether in BaselineOf or Cargo). Peter

4 6

Baseline question
by Stephane Ducasse July 1, 2017

July 1, 2017

Hi I 'm trying to define a baseline for our project and I defined it as baseline: spec <baseline> spec for: #common do: [ spec baseline: 'SmaCC' with: [ spec repository: 'github://ThierryGoubier/SmaCC'; loads: 'SmaCC-GLR-Runtime' ]; package: 'SmaCC-Solidity' "we could say that SmaccSolidity depends on Smacc-Runtime but I do not know how to say it" ] Now I thought that I could try to load it using the following Metacello new baseline: 'SmaccSolidity'; repository: 'github://RMODINRIA-Blockchain/SmaCC-Solidity'; load. But I get an error telling me that the baseline constructor does not understand load ;( I read the blog of peter https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-p… and I'm doing exactly the same so I wonder. Stef

3 2

[FT improvements] [GSoC] [guidance needed] move some of the data source responsibilities to the cells
by Elhamer July 1, 2017

July 1, 2017

Dear Pharo community, I've been working on improving the FT package recently and i would like to get your opinions about introducing a new cell data source layer. The idea is to move some of the data source responsibilities to the <cell data source, cell morph> in order to have a 'less dumber cell morphs' and a better design that reduces the complexity of extending the functionalities of a fast table. The changes are kind of expensive and might break Glamour and some other FT-based packages out there (unless the new implementation is integrated in the FT package as an alternative way -the old implementation will be deprecated and removed progressively-). There three main parts in the fast table package: - The data source - The table Morph - The cell Morph In the current design, all data managements are centralized around the data source. The Data source has the following responsibilities (schema below): - Creates the cell Morphs and populate them (cellColumn: column row: rowIndex). - Creates the header cells Morphs. - Manipulates the data that will be used to populate the table. - Updates the cell data (when the strong selection announcement is handled for example). <http://forum.world.st/file/n4952783/old_impl.png> * Limitation of this design:* - A high level of complexity in the data source. - The cell morph is a dumb object and itâs not being used to its full potential. - Extending the cell functionalities (usually done from the data source) can be challenging. A better design would be for the cell morph to interact directly with a new layer of data source âthe cell data sourceâ, and the cell's data source will propagate to the tableâs data source (the table refresh will triggered from the table's data source). Here are the responsibilities for each part (schema below): *The cell Morph responsibilities:* - Handle mouse/keyboard events and fire announcements. *The cell data source responsibilities:* - Handles cellâs announcements and manage cellâs data. - Propagates the changes to the data source. - Creates the cell morphs. *The tableâs data source responsibilities:* - Send refresh messages to the table morph when data changed. - Create the cell data sources object for each data element. *The table morph responsibilities:* - Render the morphs/widgets â¦ - Handle column/row selection. - â¦ <http://forum.world.st/file/n4952783/new_impl.png> *Requirement changes:* *The cell data source:* - A light version of the data source package to manage cell content. - â¦ *Announcements:* - Create new cells announcements that propagate the required properties to the cell's data source to handle data changes. - Propagate those announcements when the required event is fired on the cell morph. - â¦ *The data source* - Creates cells' data sources instead of cell Morphs. - â¦ *The cell Morph* - Fires the announcements, plus some tiny changes to bound the morph to its data source. - â¦ *The table Morph* - The FTTableMorph doesnât need much modification, just few changes here and there, The FTTableContainerMorph might be improved as well to take advantage from the fact that the cell morph knows its data (probably a better exposed-rows updates). - â¦ *Notes:* - These updates will definitely break Glamour, so some changes to the Glamour FT package is also required. - The best way to introduce these changes is by adding this new cell data source layer side by side with the current implementation, and mark the old implementation as deprecated (will be removed progressively in the next versions). Thank you :) Best regards, Elhamer. -- View this message in context: http://forum.world.st/FT-improvements-GSoC-guidance-needed-move-some-of-the… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

2 2

Re: [Pharo-dev] [Pharo-users] Custom Glamour browser for Dr. Geo scripting
by Nicolai Hess July 1, 2017

July 1, 2017

2017-06-30 9:55 GMT+02:00 Hilaire <hilaire(a)drgeo.eu>: > I extended the browser definition with: > > browser transmit > from: #scripts; > from: #categories; > to: #methods; > when: [ :a :b | a isMeta not ]; > andShow: [:a | self methodsIn: a ]. > browser transmit > from: #scripts; > from: #categories; > to: #methods; > when: [ :a | a isMeta ]; > andShow: [:a | self classMethodsIn: a ]. > > > However it does not work as #when: message always receive a class, so > the wrong methods a re list in the method pane. > > I enclosed a Fileout of the browser. It works independently of DrGeo. > When one select class methods, still the instance methods are displayed > in right most pane. > > Any tips? > I don't have a solution. I just want to make more clear what the problem is. See attached screenshot. The question is, is it possible to make the population of the "methods" list dependent of the focused "Instance Methods"/"Class Methods" pane ? I tried to wire a "#focus" port, but I don't think the "categories"-pane exports any port that could be used to distinguish between the selected tabs. > > Thanks > > Hilaire > > > Le 29/06/2017 Ã 14:59, Hilaire a Ã©crit : > > but something is missing to get the listed method right depending on the > > category is instance or class side. I don't how to do it. > > -- > Dr. Geo > http://drgeo.eu > >

1 0