- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Pavel Krivanek

The PR is updated -- Pavel 2017-06-30 16:44 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Attached is the changeset as discussed in my last email. > > Just to be clear, this is just for reference, I'm happy to redo the PR > if it will save you and/or Pavel some time. > > Cheers, > Alistair > > > On 30 June 2017 at 16:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef, > > > > Good pickup. > > > > I also can't load > > SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. > > Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I > > have no idea what that is (I don't remember ever creating it, and I > > don't have a copy on my machine anywhere, or in any of my backups). > > > > Fortunately I do have a changeset of the patch. I'll send it through > > as an attachment after I've sent this email in case it causes the > > response to be blocked. > > > > Do you or Pavel have a preference on how to get the PR fixed? I'm > > happy to generate a new PR if you or Pavel can close the existing one > > (#126). > > > > Thanks, > > Alistair > > > > > > On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Hi alistair > >> > >> I'm starting to review code that is in the PR pipeline. > >> https://github.com/pharo-project/pharo/pull/126 > >> > >> I noticed that you wrote in the slice > >> > >> Changes since last slice: > >> > >> - Change Path>>fullName to just print the path > >> - Fix absolute path strings > >> - Bug fix Path class>>from:delimiter: > >> - Add unit tests > >> > >> But I only see in the PR three methods. > >> Can you check because I have the impression that we are losing code > somewhere? > >> > >> BTW I could not see the contents of the AlistairGrant.1 package > >> I tried on several images 70 and 60 latest > >> > >> Stef > >> >

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Alistair Grant

Attached is the changeset as discussed in my last email. Just to be clear, this is just for reference, I'm happy to redo the PR if it will save you and/or Pavel some time. Cheers, Alistair On 30 June 2017 at 16:42, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > Good pickup. > > I also can't load > SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. > Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I > have no idea what that is (I don't remember ever creating it, and I > don't have a copy on my machine anywhere, or in any of my backups). > > Fortunately I do have a changeset of the patch. I'll send it through > as an attachment after I've sent this email in case it causes the > response to be blocked. > > Do you or Pavel have a preference on how to get the PR fixed? I'm > happy to generate a new PR if you or Pavel can close the existing one > (#126). > > Thanks, > Alistair > > > On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Hi alistair >> >> I'm starting to review code that is in the PR pipeline. >> https://github.com/pharo-project/pharo/pull/126 >> >> I noticed that you wrote in the slice >> >> Changes since last slice: >> >> - Change Path>>fullName to just print the path >> - Fix absolute path strings >> - Bug fix Path class>>from:delimiter: >> - Add unit tests >> >> But I only see in the PR three methods. >> Can you check because I have the impression that we are losing code somewhere? >> >> BTW I could not see the contents of the AlistairGrant.1 package >> I tried on several images 70 and 60 latest >> >> Stef >>

June 30, 2017

Re: [Pharo-dev] About Fogbugz 20165 Support-segment-path-printing

by Alistair Grant

Hi Stef, Good pickup. I also can't load SLICE-Issue-20165-Support-segment-path-printing-AlistairGrant.1. Somehow it is dependent on FileSystem-Core-AlistairGrant.223, and I have no idea what that is (I don't remember ever creating it, and I don't have a copy on my machine anywhere, or in any of my backups). Fortunately I do have a changeset of the patch. I'll send it through as an attachment after I've sent this email in case it causes the response to be blocked. Do you or Pavel have a preference on how to get the PR fixed? I'm happy to generate a new PR if you or Pavel can close the existing one (#126). Thanks, Alistair On 30 June 2017 at 16:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi alistair > > I'm starting to review code that is in the PR pipeline. > https://github.com/pharo-project/pharo/pull/126 > > I noticed that you wrote in the slice > > Changes since last slice: > > - Change Path>>fullName to just print the path > - Fix absolute path strings > - Bug fix Path class>>from:delimiter: > - Add unit tests > > But I only see in the PR three methods. > Can you check because I have the impression that we are losing code somewhere? > > BTW I could not see the contents of the AlistairGrant.1 package > I tried on several images 70 and 60 latest > > Stef >

June 30, 2017

About Fogbugz 20165 Support-segment-path-printing

by Stephane Ducasse

Hi alistair I'm starting to review code that is in the PR pipeline. https://github.com/pharo-project/pharo/pull/126 I noticed that you wrote in the slice Changes since last slice: - Change Path>>fullName to just print the path - Fix absolute path strings - Bug fix Path class>>from:delimiter: - Add unit tests But I only see in the PR three methods. Can you check because I have the impression that we are losing code somewhere? BTW I could not see the contents of the AlistairGrant.1 package I tried on several images 70 and 60 latest Stef

June 30, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60505 Home: https://github.com/pharo-project/pharo-core

June 30, 2017

[pharo-project/pharo-core] d09696: 60505

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d096961f099012edaa6a1447bb0868a7abfe34db https://github.com/pharo-project/pharo-core/commit/d096961f099012edaa6a1447… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-30 (Fri, 30 Jun 2017) Changed paths: M AST-Core.package/RBProgramNode.class/instance/accessing/comments_.st M CodeImport.package/ChunkReadStream.class/instance/decorated/parseLangTagFor_.st M Collections-Strings.package/String.class/instance/converting/withNoLineLongerThan_.st M ConfigurationCommandLineHandler-Core.package/ConfigurationCommandLineHandler.class/instance/printing/printConfigurations_.st M Files.package/MultiByteFileStream.class/instance/fileIn%2FOut/nextChunk.st M Files.package/MultiByteFileStream.class/instance/fileIn%2FOut/nextPreamble.st M Graphics-Display Objects.package/Form.class/instance/other/fillAlpha_.st M Jobs.package/Job.class/class/examples/exampleCurrentValue.st M Kernel.package/Protocol.class/instance/initialization/initialize.st M Multilingual-TextConversion.package/UTF16TextConverter.class/instance/conversion/nextFromStream_.st M OpalCompiler-Core.package/IRBytecodeDecompiler.class/instance/instruction decoding/jump_.st M OpalCompiler-Core.package/IRPrinterV2.class/instance/visiting/visitPopIntoRemoteTemp_.st M OpalCompiler-Core.package/IRPrinterV2.class/instance/visiting/visitPushRemoteTemp_.st M OpalCompiler-Core.package/IRPrinterV2.class/instance/visiting/visitStoreRemoteTemp_.st M OpalCompiler-Core.package/IRReconstructor.class/instance/initialize/createTempVectorNamed_withVars_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60504.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60505.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60504.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60505.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/TemporaryVariable.class/instance/comparing/hash.st M System-Sources.package/PharoChangesCondenser.class/instance/initialization/reset.st M System-Sources.package/SourceFileArray.class/instance/private - copying/readOnlyCopy.st M Text-Core.package/Text.class/class/initialization/initialize.st M Text-Core.package/Text.class/class/instance creation/fromString_.st M Text-Core.package/TextFontChange.class/class/as yet unclassified/defaultFontChange.st M Traits.package/TBehaviorCategorization.class/instance/organization/category.st M UIManager.package/UIManager.class/instance/ui process/spawnNewProcess.st M Zinc-HTTP.package/ZnImageExampleDelegate.class/instance/accessing/html.st M Zodiac-Core.package/ZdcPluginSSLSession.class/instance/accessing/serverName_.st Log Message: ----------- 60505 20187 Request use of block in certain methods https://pharo.fogbugz.com/f/cases/20187 20188 Request representation of integer literal without float exponent https://pharo.fogbugz.com/f/cases/20188 20182 Extra dot in literal array https://pharo.fogbugz.com/f/cases/20182 18760 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions https://pharo.fogbugz.com/f/cases/18760 20186 Request removal of extra statement separators (dot) https://pharo.fogbugz.com/f/cases/20186 http://files.pharo.org/image/60/60505.zip

June 30, 2017

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

I have done some work on packaging up pharo projects for Nix so that images can be created in the sandboxed build environment. I am a bit stuck though. I have a script that takes a project named and creates a specification of all the required mcz files, recursing into dependencies: Here is the spec for a small project, NeoJSON: [ { name = "ConfigurationOfNeoJSON-SvenVanCaekenberghe.20"; package = "ConfigurationOfNeoJSON-SvenVanCaekenberghe.20"; url = " http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main//ConfigurationOfNe… "; sha256 = "0y5yqmb2hjfya2s4a8pkrz0q6pdm01vrfhvfj5knk6slgsy8c2my"; } { name = "Neo-JSON-Core-SvenVanCaekenberghe.37"; package = "Neo-JSON-Core-SvenVanCaekenberghe.37"; url = " http://mc.stfx.eu/Neo/Neo-JSON-Core-SvenVanCaekenberghe.37.mcz"; sha256 = "054hcp1lcriby5a8gpc54gcrd9agbpjv6f0n81bk7f091n9m01z0"; } { name = "Neo-JSON-Tests-SvenVanCaekenberghe.36"; package = "Neo-JSON-Tests-SvenVanCaekenberghe.36"; url = " http://mc.stfx.eu/Neo/Neo-JSON-Tests-SvenVanCaekenberghe.36.mcz"; sha256 = "1c3nxi09l785npjypjmzcn5bhy5sswp1agj7pfqs640vg7l80l4k"; } ] Nix then uses this to construct a package cache directory with a local copy of each mcz file: $ ls -1 /nix/store/41jbwrsdpcvh684ll3qqk9lcfrrvxy59-pharo-package-cache/ ConfigurationOfNeoJSON-SvenVanCaekenberghe.20.mcz Neo-JSON-Core-SvenVanCaekenberghe.37.mcz Neo-JSON-Tests-SvenVanCaekenberghe.36.mcz So this looks promising: I have all the code and should be able to load it without using the network. However - I do in practice get an error when I try to do this. I guess Metacello wants to access the network for some reasons I have not anticipated. Here is my script: Metacello new configuration: 'NeoJSON'; cacheRepository: '/nix/store/rdy7wp3cx4z86wy537idkhjb0q70xzjp-pharo-package-cache/'; ignoreImage; load. Smalltalk saveAs: 'pharo'. Smalltalk exitSuccess. and my Metacello error here: https://gist.github.com/lukego/ab105c257457e7b9a53f6378425df9a8 Any advice to make this work? (Could I perhaps bypass Metacello entirely and just load the mcz files directly? Guessing not...?)

June 30, 2017

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

by Norbert Hartl

Hi, > Am 30.06.2017 um 12:03 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Hi > > recently I started to read a book on machine learning and they > manipulate dictionary of dictionary. (So I started my own > implementation and I will switch to DataFrame). > having an abstract notation for a structure (or dictionary of dictionary) is something really useful. I work a lot with JSON and the creation in pharo is done the same way but you have to call asDictionary all the time which is annoying. This can be rethought and would make things less ugly if we had a good way. If it is close to S-expressions the better. But what is DataFrame? > Now it occurred to me that when we program complex objects we do not > need a compact literal syntax for our objects. But when we manipulate > data objects it is super handy. > > I ended up doing a lot of > > self new > addRow: 'Claudia Puig' > withTaggedValues: > {('Snakes on a Plane' -> 3.5). ('Just My Luck' -> 3.0). > ('The Night Listener' -> 4.5). ('Superman Returns' -> 4.0). ('You, Me > and Dupree' -> 2.5)}. > > And I was not in the mood to write a class for the taggedValues and > writing a class would not have really help me. > > > Now we also have STON but STON is not yet part of the language > grammar. So we have to have an explicit conversion call. > > 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. 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. 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.

June 30, 2017

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

by Stephane Ducasse

for fun I implemented asObjectOf: MCSmalltalkhubRepository owner: 'StephaneDucasse' project: 'asObjectOf' user: '' password: '' On Fri, Jun 30, 2017 at 12:03 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > recently I started to read a book on machine learning and they > manipulate dictionary of dictionary. (So I started my own > implementation and I will switch to DataFrame). > > Now it occurred to me that when we program complex objects we do not > need a compact literal syntax for our objects. But when we manipulate > data objects it is super handy. > > I ended up doing a lot of > > self new > addRow: 'Claudia Puig' > withTaggedValues: > {('Snakes on a Plane' -> 3.5). ('Just My Luck' -> 3.0). > ('The Night Listener' -> 4.5). ('Superman Returns' -> 4.0). ('You, Me > and Dupree' -> 2.5)}. > > And I was not in the mood to write a class for the taggedValues and > writing a class would not have really help me. > > > Now we also have STON but STON is not yet part of the language > grammar. So we have to have an explicit conversion call. > > STON fromString: 'Point[10,20]' > > 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. > > 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.

June 30, 2017

Re: [Pharo-dev] [FT improvements] [GSoC] [guidance needed] move some of the data source responsibilities to the cells

by Elhamer

Since there are no response, I am guessing that this design is okay and i will go for it :D. Best, 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.

June 30, 2017