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

Re: [Pharo-dev] [Ann] Class meta annotations

by Denis Kudriashov

2017-10-04 9:48 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > I'd even call them First class pragmas from that point of view :P > Yes. But we decided avoid pragma related names here. Because in future it can be possible to add normal pragmas into the class definition. > > I wonder what are the side-effects of instantiating the annotation > yourself in a method. > > specialAnnotationExample > <classAnnotation> > ^MySpecialAnnotation new > I not understand the question. You supposed to return an *instance* of the annotation from the "annotating method". > > I mean, I understand we can use the class state to initialize the > annotation. But the fact that the annotation is cached after its first > instantiation means that the annotation will not necessarily evolve as the > class evolves. > Cache is updated after related class changes: method added, removed and so on (driven by PragmaCollector logic). So outdated annotations should not exist. Is it what you ask? > Do we want annotations to be stateless? Or depend only in literals? > I want annotations to be any object with any state inside. Of course you will be restricted by what is visible from the class side. But in "annotating method" you can create any complex object (see below). > I wonder then what is the main difference with > > specialAnnotationExample > <classAnnotation: MySpecialAnnotation> > > And what is the impact of having an annotation with parameters. > Generally it is same like having pragma with parameters. But with annotation you are not restricted by literal objects. So annotation parameters can be anything. And it is important feature for Commander. For example I need instance of KMKeyCombination to define shortcut for command. So I just use normal expression for this: RenamePackageCommand class>>packageBrowserShortcutActivation <classAnnotation> ^CmdShortcutCommandActivation by: *$r meta* for: ClyPackageBrowserContext It will be very complicated to express it with method pragma and it will be restricted anyway. Another important point is that class annotation is first class object which means that you can add behaviour to it. With method pragma you can not. For example shortcut annotation includes method to check given key event and execute command if it is satisfied. Is it now clear? > On Tue, Oct 3, 2017 at 9:02 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Denis Kudriashov wrote >> > If you will use method pragma then you will repeat logic of this >> library: >> > In your code you will need... >> >> So it sounds like it's pragmas++ - the functionality of pragmas plus some >> other stuff you may need that you'd have to roll on your own >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 4, 2017

Re: [Pharo-dev] String Interpolation

by Thierry Goubier

2017-10-04 9:50 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > if the compiler plugin correctly models such special syntax with special > AST nodes, that could be even possible without much effort > Interesting. Would that imply that by having those special ast nodes, we would get the decompilation working for the debugger? Thierry > > On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-10-03 17:39 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> Hi. >>> >>> While idea looks cool it will require a lot of tool support. Senders, >>> var/class references, rename refactorings should be aware of it >>> >> >> And I forgot debugger. It should be possible to step over "interpolated >> expressions" >> >> >>> >>> 2017-10-03 17:29 GMT+02:00 Damien Pollet <damien.pollet(a)gmail.com>: >>> >>>> On 3 October 2017 at 14:07, Guillermo Polito <guillermopolito(a)gmail.com >>>> > wrote: >>>> >>>>> Why not having an opal plugin? >>>>> >>>>> The opal plugin may read strings in the form: >>>>> >>>>> "lalala {some expression} lololo" >>>>> >>>>> and replace at compile time that by: >>>>> >>>>> "lalala {1} lololo" format { some expression } >>>>> >>>> >>>> If we're going to extend the compiler, we might as avoid parsing at >>>> runtime by desugaring more like: >>>> >>>> String streamContents: [:str | >>>> str >>>> nextPutAll: 'lalala '; >>>> nextPutAll: (some expression) printString; >>>> nextPutAll: ' lololo' ] >>>> >>>> The thing to think about is what is the delimiter for {some expression}. >>>>> - a too used one may break lots of existing code. >>>>> >>>> >>>> â¦or we could change the string quotes to mean "dynamic string in which >>>> interpolations can be used" and keep single quotes for literal strings only. >>>> >>>> - and we should escape it >>>>> >>>> >>>> indeed >>>> >>>> >>>>> On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> > On 29 Sep 2017, at 08:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>>> wrote: >>>>>> > >>>>>> > This solution will not work for environments without sources too >>>>>> where names like t1, t2 are used for temporary variables. >>>>>> >>>>>> That is true. >>>>>> >>>>>> I often wonder why we can't keep at least the variables names, it >>>>>> would not be that expensive. There was this problem with FFI that needed >>>>>> source code access as well. It would also help the debugger and make the >>>>>> decompiler more powerful. >>>>>> >>>>>> > Anyway, nice idea. >>>>>> > >>>>>> > -- Pavel >>>>>> > >>>>>> > Dne Ätvrtek 28. zÃ¡ÅÃ 2017 Sven Van Caekenberghe <sven(a)stfx.eu> >>>>>> napsal(a): >>>>>> > Hi, >>>>>> > >>>>>> > I got into a little office discussion about string interpolation as >>>>>> it is done in different programming languages. >>>>>> > >>>>>> > In Pharo we have String>>#format: which is pretty nice. It works as >>>>>> follows: >>>>>> > >>>>>> > | x y | >>>>>> > x := 123. >>>>>> > y := #foo. >>>>>> > 'x={1} and y={2}' format: { x. y }. >>>>>> > >>>>>> > It is also possible to use a dictionary with keys, like this: >>>>>> > >>>>>> > | x y | >>>>>> > x := 123. >>>>>> > y := #foo. >>>>>> > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. >>>>>> > >>>>>> > But this is not true string interpolation as described in [ >>>>>> https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to >>>>>> write the value generating expressions directly inside the strings. >>>>>> > >>>>>> > Since in Pharo we add features not by extending the syntax but by >>>>>> adding messages I wondered if it could be done for string interpolation. >>>>>> The goal is to make the following work: >>>>>> > >>>>>> > | x y | >>>>>> > x := 123. >>>>>> > y := #foo. >>>>>> > 'It seems x equals {x} and y equals {y} while Pi is still {Float >>>>>> pi}' interpolate. >>>>>> > >>>>>> > => 'It seems x equals 123 and y equals foo while Pi is still >>>>>> 3.141592653589793' >>>>>> > >>>>>> > Here is the implementation I came up with: >>>>>> > >>>>>> > String>>#interpolate >>>>>> > "Format the receiver by interpolating the evaluation of >>>>>> expressions >>>>>> > in between curly brackets in the context of the sender as in the >>>>>> following 3 oneline examples. >>>>>> > 'Today is {Date today}' interpolate. >>>>>> > | x | x := 123. 'x equals {x} and pi equals {Float pi}' >>>>>> interpolate. >>>>>> > 'In {#strings} you can escape \{ by prefixing it with \\' >>>>>> interpolate." >>>>>> > >>>>>> > | senderContext | >>>>>> > senderContext := thisContext sender. >>>>>> > ^ self class new: self size streamContents: [ :out | | stream | >>>>>> > stream := self readStream. >>>>>> > [ stream atEnd ] whileFalse: [ | currentChar | >>>>>> > (currentChar := stream next) == ${ >>>>>> > ifTrue: [ | expression result | >>>>>> > expression := stream upTo: $}. >>>>>> > result := Compiler new >>>>>> > evaluate: expression in: senderContext to: nil >>>>>> notifying: nil ifFail: [ ^ nil ] logged: false. >>>>>> > out nextPutAll: result asString ] >>>>>> > ifFalse: [ >>>>>> > currentChar == $\ >>>>>> > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream >>>>>> next ] ] >>>>>> > ifFalse: [ out nextPut: currentChar ] ] ] ] >>>>>> > >>>>>> > It is a hack that could certainly be improved. And there is of >>>>>> course an obvious security problem. >>>>>> > >>>>>> > Thoughts ? >>>>>> > >>>>>> > Sven >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> Guille Polito >>>>> >>>>> Research Engineer >>>>> >>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>> >>>>> CRIStAL - UMR 9189 >>>>> >>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>> <http://www.cnrs.fr>* >>>>> >>>>> >>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>> >>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>> >>>> >>>> >>>> >>>> -- >>>> Damien Pollet >>>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>>> >>> >>> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 4, 2017

Re: [Pharo-dev] String Interpolation

by Guillermo Polito

if the compiler plugin correctly models such special syntax with special AST nodes, that could be even possible without much effort On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-10-03 17:39 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Hi. >> >> While idea looks cool it will require a lot of tool support. Senders, >> var/class references, rename refactorings should be aware of it >> > > And I forgot debugger. It should be possible to step over "interpolated > expressions" > > >> >> 2017-10-03 17:29 GMT+02:00 Damien Pollet <damien.pollet(a)gmail.com>: >> >>> On 3 October 2017 at 14:07, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> >>>> Why not having an opal plugin? >>>> >>>> The opal plugin may read strings in the form: >>>> >>>> "lalala {some expression} lololo" >>>> >>>> and replace at compile time that by: >>>> >>>> "lalala {1} lololo" format { some expression } >>>> >>> >>> If we're going to extend the compiler, we might as avoid parsing at >>> runtime by desugaring more like: >>> >>> String streamContents: [:str | >>> str >>> nextPutAll: 'lalala '; >>> nextPutAll: (some expression) printString; >>> nextPutAll: ' lololo' ] >>> >>> The thing to think about is what is the delimiter for {some expression}. >>>> - a too used one may break lots of existing code. >>>> >>> >>> â¦or we could change the string quotes to mean "dynamic string in which >>> interpolations can be used" and keep single quotes for literal strings only. >>> >>> - and we should escape it >>>> >>> >>> indeed >>> >>> >>>> On Fri, Sep 29, 2017 at 5:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>>> wrote: >>>> >>>>> >>>>> >>>>> > On 29 Sep 2017, at 08:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>>>> wrote: >>>>> > >>>>> > This solution will not work for environments without sources too >>>>> where names like t1, t2 are used for temporary variables. >>>>> >>>>> That is true. >>>>> >>>>> I often wonder why we can't keep at least the variables names, it >>>>> would not be that expensive. There was this problem with FFI that needed >>>>> source code access as well. It would also help the debugger and make the >>>>> decompiler more powerful. >>>>> >>>>> > Anyway, nice idea. >>>>> > >>>>> > -- Pavel >>>>> > >>>>> > Dne Ätvrtek 28. zÃ¡ÅÃ 2017 Sven Van Caekenberghe <sven(a)stfx.eu> >>>>> napsal(a): >>>>> > Hi, >>>>> > >>>>> > I got into a little office discussion about string interpolation as >>>>> it is done in different programming languages. >>>>> > >>>>> > In Pharo we have String>>#format: which is pretty nice. It works as >>>>> follows: >>>>> > >>>>> > | x y | >>>>> > x := 123. >>>>> > y := #foo. >>>>> > 'x={1} and y={2}' format: { x. y }. >>>>> > >>>>> > It is also possible to use a dictionary with keys, like this: >>>>> > >>>>> > | x y | >>>>> > x := 123. >>>>> > y := #foo. >>>>> > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. >>>>> > >>>>> > But this is not true string interpolation as described in [ >>>>> https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to >>>>> write the value generating expressions directly inside the strings. >>>>> > >>>>> > Since in Pharo we add features not by extending the syntax but by >>>>> adding messages I wondered if it could be done for string interpolation. >>>>> The goal is to make the following work: >>>>> > >>>>> > | x y | >>>>> > x := 123. >>>>> > y := #foo. >>>>> > 'It seems x equals {x} and y equals {y} while Pi is still {Float >>>>> pi}' interpolate. >>>>> > >>>>> > => 'It seems x equals 123 and y equals foo while Pi is still >>>>> 3.141592653589793' >>>>> > >>>>> > Here is the implementation I came up with: >>>>> > >>>>> > String>>#interpolate >>>>> > "Format the receiver by interpolating the evaluation of expressions >>>>> > in between curly brackets in the context of the sender as in the >>>>> following 3 oneline examples. >>>>> > 'Today is {Date today}' interpolate. >>>>> > | x | x := 123. 'x equals {x} and pi equals {Float pi}' >>>>> interpolate. >>>>> > 'In {#strings} you can escape \{ by prefixing it with \\' >>>>> interpolate." >>>>> > >>>>> > | senderContext | >>>>> > senderContext := thisContext sender. >>>>> > ^ self class new: self size streamContents: [ :out | | stream | >>>>> > stream := self readStream. >>>>> > [ stream atEnd ] whileFalse: [ | currentChar | >>>>> > (currentChar := stream next) == ${ >>>>> > ifTrue: [ | expression result | >>>>> > expression := stream upTo: $}. >>>>> > result := Compiler new >>>>> > evaluate: expression in: senderContext to: nil >>>>> notifying: nil ifFail: [ ^ nil ] logged: false. >>>>> > out nextPutAll: result asString ] >>>>> > ifFalse: [ >>>>> > currentChar == $\ >>>>> > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream >>>>> next ] ] >>>>> > ifFalse: [ out nextPut: currentChar ] ] ] ] >>>>> > >>>>> > It is a hack that could certainly be improved. And there is of >>>>> course an obvious security problem. >>>>> > >>>>> > Thoughts ? >>>>> > >>>>> > Sven >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >> >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 4, 2017

Re: [Pharo-dev] [Ann] Class meta annotations

by Guillermo Polito

I'd even call them First class pragmas from that point of view :P I wonder what are the side-effects of instantiating the annotation yourself in a method. specialAnnotationExample <classAnnotation> ^MySpecialAnnotation new I mean, I understand we can use the class state to initialize the annotation. But the fact that the annotation is cached after its first instantiation means that the annotation will not necessarily evolve as the class evolves. Do we want annotations to be stateless? Or depend only in literals? I wonder then what is the main difference with specialAnnotationExample <classAnnotation: MySpecialAnnotation> And what is the impact of having an annotation with parameters. On Tue, Oct 3, 2017 at 9:02 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Denis Kudriashov wrote > > If you will use method pragma then you will repeat logic of this library: > > In your code you will need... > > So it sounds like it's pragmas++ - the functionality of pragmas plus some > other stuff you may need that you'd have to roll on your own > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 4, 2017

Re: [Pharo-dev] Iceberg - loading baseline

by Jan BlizniÄenko

I think I got it. The correct code for me is SystemSettingsPersistence updateSettingNodes. Metacello new baseline: 'NameOfMyProject'; repository: 'gitlocal:///C:/Users/User/Pharo/repo/nameofmyproject/filetree'; load. First line loads my stored settings that look like this for Iceberg: http://www.mediafire.com/view/br6isyeo69z1mqe/2017-10-03.png and the second line puts my already existing git clone in filesystem into Iceberg and successfully loads the baseline with all dependencies. So problem solved for me. Esteban, your code is, I guess, for loading the code directly from GitLab without having local clone first, into default location of Iceberg, right? Anyway that inspired me to remove my first part of code and that was what I needed :) Thank you Jan Jan BlizniÄenko wrote > Hello > > Unfortunately removing the /filetree does not seem to change anything - I > end up with same error. If I run the code without /filetree, however, it > creates the entry in Iceberg and then I can load it manually package by > package via Iceberg GUI, but I cannot run the baseline either by this > code, > or by right clicking the baseline package and selecting "Install baseline > (default)", because even that ends with the very same exception as my code > (Could not resolve:...). > > When I tried your code, either with or without /filetree, it ends up with > LGit_GIT_EEOF: ERROR: Repository not found. I debugged it and found out it > tries to find > git@ > :bliznjan/nameofmyproject.git but my project is > on gitlab, not github. The problem may lie somewhere around > IceProviderRepositoryType>>#mcRepository > which contains creation of MCGitHubRepository even for an instance of > IceGitlabRepositoryType? > > Also I do have Metacello integration checked, these are my Iceberg > settings: > http://www.mediafire.com/view/br6isyeo69z1mqe/2017-10-03.png > > Jan > > > > EstebanLM wrote >>> On 3 Oct 2017, at 08:47, Jan BlizniÄenko < > >> bliznjan@.cvut > >> > wrote: >>> >>> Hello >>> >>> I have a local clone of git repository and I am looking for code that >>> adds >>> this repository to Iceberg and then loads its baseline into Pharo. I am >>> using Pharo 6.1 (image 60510) and last stable Windows VM. >>> >>> Right now I am experimenting with following code, it adds the project >>> into >>> Iceberg, but does not load the baseline. The code is: >>> >>> SystemSettingsPersistence updateSettingNodes. "sets ssh key locations" >>> >>> (Smalltalk at: #IceRepositoryCreator) new >>> url: ' > >> git@ > >> :bliznjan/nameofmyproject.git'; >>> location: '/C:/Users/User/Pharo/repo/nameofmyproject/filetree' >>> asFileReference; >>> subdirectory: 'filetree'; >>> createRepository. "this part seems to work fineâ >> >> I think this is your error: >> '/C:/Users/User/Pharo/repo/nameofmyproject/filetree, needs to be >> '/C:/Users/User/Pharo/repo/nameofmyproject (without the filetree part, >> which is the subdirectory) >> >> now, I think if you do: >> >> Metacello new >> repository: âgitlab://bliznjan/nameofmyproject/filetree' >> <gitlab://bliznjan/nameofmyproject/filetree'>; >> baseline: âMyProjectâ >> load. >> >> ir will also do what you want without the two steps. >> >>> >>> Metacello new baseline: 'NameOfMyProject'; repository: >>> 'gitlocal:///C:/Users/User/Pharo/repo/nameofmyproject/filetree'; load. >>> "this >>> one fails with exception below" >>> >>> >>> loading the baseline ends with Exception >>> Could not resolve: BaselineOfNameOfMyProject >>> [BaselineOfNameOfMyProject] >>> in C:\Users\User\Pharo\images\TestingImage1\pharo-local\package-cache >>> C:\Users\User\Pharo\repo\nameofmyproject\filetree (Libgit) >>> >>> Those paths seem correct - the package-cache is located in exactly that >>> position (but does not contain anything that relates to my project) and >>> the >>> filetree (repository) in the mentioned path and there is a >>> BaselineOfNameOfMyProject.package directory in there. >>> >>> Also, if I then try loading the baseline manually via Iceberg, by right >>> clicking on BaselineOfNameOfMyProject in Packages tab, I get exactly >>> same >>> exception. >>> >>> Loading packages one by one manually via Iceberg Packages tab works. >>> Also, >>> loading the baseline via GitFileTree works. >>> >>> Thank you >>> Jan >>> >>> >>> >>> -- >>> Sent from: >>> http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 4, 2017

Re: [Pharo-dev] Iceberg - loading baseline

by Jan BlizniÄenko

Hello Unfortunately removing the /filetree does not seem to change anything - I end up with same error. If I run the code without /filetree, however, it creates the entry in Iceberg and then I can load it manually package by package via Iceberg GUI, but I cannot run the baseline either by this code, or by right clicking the baseline package and selecting "Install baseline (default)", because even that ends with the very same exception as my code (Could not resolve:...). When I tried your code, either with or without /filetree, it ends up with LGit_GIT_EEOF: ERROR: Repository not found. I debugged it and found out it tries to find git@github.com:bliznjan/nameofmyproject.git but my project is on gitlab, not github. The problem may lie somewhere around IceProviderRepositoryType>>#mcRepository which contains creation of MCGitHubRepository even for an instance of IceGitlabRepositoryType? Also I do have Metacello integration checked, these are my Iceberg settings: http://www.mediafire.com/view/br6isyeo69z1mqe/2017-10-03.png Jan EstebanLM wrote >> On 3 Oct 2017, at 08:47, Jan BlizniÄenko < > bliznjan@.cvut > > wrote: >> >> Hello >> >> I have a local clone of git repository and I am looking for code that >> adds >> this repository to Iceberg and then loads its baseline into Pharo. I am >> using Pharo 6.1 (image 60510) and last stable Windows VM. >> >> Right now I am experimenting with following code, it adds the project >> into >> Iceberg, but does not load the baseline. The code is: >> >> SystemSettingsPersistence updateSettingNodes. "sets ssh key locations" >> >> (Smalltalk at: #IceRepositoryCreator) new >> url: ' > git@ > :bliznjan/nameofmyproject.git'; >> location: '/C:/Users/User/Pharo/repo/nameofmyproject/filetree' >> asFileReference; >> subdirectory: 'filetree'; >> createRepository. "this part seems to work fineâ > > I think this is your error: > '/C:/Users/User/Pharo/repo/nameofmyproject/filetree, needs to be > '/C:/Users/User/Pharo/repo/nameofmyproject (without the filetree part, > which is the subdirectory) > > now, I think if you do: > > Metacello new > repository: âgitlab://bliznjan/nameofmyproject/filetree' > <gitlab://bliznjan/nameofmyproject/filetree'>; > baseline: âMyProjectâ > load. > > ir will also do what you want without the two steps. > >> >> Metacello new baseline: 'NameOfMyProject'; repository: >> 'gitlocal:///C:/Users/User/Pharo/repo/nameofmyproject/filetree'; load. >> "this >> one fails with exception below" >> >> >> loading the baseline ends with Exception >> Could not resolve: BaselineOfNameOfMyProject [BaselineOfNameOfMyProject] >> in C:\Users\User\Pharo\images\TestingImage1\pharo-local\package-cache >> C:\Users\User\Pharo\repo\nameofmyproject\filetree (Libgit) >> >> Those paths seem correct - the package-cache is located in exactly that >> position (but does not contain anything that relates to my project) and >> the >> filetree (repository) in the mentioned path and there is a >> BaselineOfNameOfMyProject.package directory in there. >> >> Also, if I then try loading the baseline manually via Iceberg, by right >> clicking on BaselineOfNameOfMyProject in Packages tab, I get exactly same >> exception. >> >> Loading packages one by one manually via Iceberg Packages tab works. >> Also, >> loading the baseline via GitFileTree works. >> >> Thank you >> Jan >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 3, 2017

Re: [Pharo-dev] pharo --help returning non-zero exit status

by Nicolas Cellier

Having the discussions scattered in Pharo-dev vm-dev github may help extending the indecision phase... There has been another important thread in vm-dev (Validation builds failing) http://lists.squeakfoundation.org/pipermail/vm-dev/2017-June/025417.html The conclusion was that we ask for some Pharo authority to approve the change We thus asked for Esteban's blessing, but unfortunately it seems that you have assigned much more work to Esteban without taking the precaution to clone him first... IMO you need about 4 or 5 Esteban. If Pharo is OK, then we can just accept the PR and clean a bit the list of stale PR 2017-10-02 15:21 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Esteban, Eliot, Clement was is the process to get this fix in the VM? > > On Sun, Oct 1, 2017 at 9:05 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Ah, perfect. Thanks! > > > > peter > > > > On Sun, Oct 1, 2017 at 8:41 AM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > >> > >> On Sunday 01 October 2017 11:27 AM, Peter UhnÃ¡k wrote: > >>> > >>> Hi, > >>> > >>> why does executing `pharo --help` return exit status 1? The operation > >>> succeeded, so I don't see a reason for a failure return state. > >> > >> > >> This is a bug. See the thread at > >> > >> > >> > >> http://forum.world.st/Re-Pharo-dev-pharo-help-returns- > exit-code-1-on-ubuntu-td4945756.html > >> > >> The proposed fix is pending review at: > >> > >> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/136 > >> > >> Regards .. Subbu > >> > >> > > > >

Oct. 3, 2017

Re: [Pharo-dev] [Ann] Class meta annotations

by Sean P. DeNigris

Denis Kudriashov wrote > If you will use method pragma then you will repeat logic of this library: > In your code you will need... So it sounds like it's pragmas++ - the functionality of pragmas plus some other stuff you may need that you'd have to roll on your own ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 3, 2017

Re: [Pharo-dev] Non-deterministic ombu errors

by Martin Dias

I've put ConfigurationOfEpicea 8.2.4 in p6 inbox. MartÃn On Tue, Oct 3, 2017 at 1:40 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi > > On Tue, Oct 3, 2017 at 11:40 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> > wrote: > >> Yes, please backport the changes to Pharo 6.1 because the travis builds >> are failing a lot with this kind of errors when you have a project with >> non-ASCII characters. >> > > Ok > > >> >> Probably it makes no sense to enable Epicea in the images used by >> SmalltalkCI. Is there some way to disable it? >> > > Sure, you can evaluate: EpMonitor reset > > > > >> >> >> On Mon, Oct 2, 2017 at 10:18 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Martin >>> >>> if you publish a fix for 6.1 we will port it back because this is >>> important. >>> >>> Stef >>> >>> On Fri, Sep 29, 2017 at 3:55 PM, Martin Dias <tinchodias(a)gmail.com> >>> wrote: >>> > Now I do not know the best way for you to get the new fixed version. >>> It's >>> > too late to include it in P6.1, I guess, so... either add epicea into >>> > metacello configuration or wait until P7. >>> > >>> > >>> > >>> > On Fri, Sep 29, 2017 at 5:34 AM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz >>> > >>> > wrote: >>> >> >>> >> I'm glad it has known reason then, thank you for looking into it, all >>> I >>> >> was >>> >> able to find out was that it relates to non-ascii characters and that >>> >> build >>> >> on our production server fails because of that :) >>> >> >>> >> Jan >>> >> >>> >> >>> >> tinchodias wrote >>> >> > On Sun, Sep 24, 2017 at 5:49 AM, Sven Van Caekenberghe < >>> >> >>> >> > sven@ >>> >> >>> >> > > wrote: >>> >> > >>> >> >> >>> >> >> > On 23 Sep 2017, at 22:42, Jan BlizniÄenko < >>> >> >>> >> > bliznjan@.cvut >>> >> >>> >> > > wrote: >>> >> >> > >>> >> >> > Hello >>> >> >> > >>> >> >> > I am having very similar errors from time to time when manually >>> >> >> > loading >>> >> >> code >>> >> >> > into Pharo from filetree (gitfiletree), but only in one of my >>> >> >> > projects >>> >> >> which >>> >> >> > contains non-ASCII characters like ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©Å¯ÃºÅ¥Ä. For the very >>> same >>> >> >> reason >>> >> >> > (not able to find why sometimes the error is there and sometimes >>> is >>> >> >> not), I >>> >> >> > did not report it yet, but it is quite annoying. Retrying >>> loading the >>> >> >> > package helps every time. >>> >> >> >>> >> >> I think was reported before. I believe Ombu somewhere takes an >>> >> >> arbitrary >>> >> >> chunk of bytes out of an UTF-8 encoded file (like the last 100 of >>> >> >> something >>> >> >> like that) and then starts reading that. With UTF-8, a variable >>> length >>> >> >> encoding, that can be dangerous because you could end up in the >>> middle >>> >> >> of >>> >> >> a >>> >> >> character, not between encoded character boundaries. This would >>> also >>> >> >> explain the randomness, as it is highly dependent on the contents. >>> >> >> >>> >> >> ZnUTF8Encoder>>#backOnStream: can be used to make sure you are >>> really >>> >> >> at >>> >> >> the start of an encoded character. >>> >> >> >>> >> > >>> >> > >>> >> > Hello >>> >> > >>> >> > This issue was reported as: >>> >> > >>> >> > >>> >> > https://pharo.fogbugz.com/f/cases/20112/Epicea-can-fail-whil >>> e-reading-non-ascii-blocks >>> >> > >>> >> > My apologies for the bug... I introduced that code as an i/o >>> >> > optimization >>> >> > but wasn't properly tested. >>> >> > >>> >> > Thnks Sven, but I finally used stream's #basicNext (as Henrik >>> suggested >>> >> > in >>> >> > fogbugz) which skips forward. >>> >> > >>> >> > >>> >> > Martin >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Sent from: http://forum.world.st/Pharo-Sm >>> alltalk-Developers-f1294837.html >>> >> >>> > >>> >>> >> >

Oct. 3, 2017

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Henrik Sperre Johansen

Denis Kudriashov wrote > Hi Henrik. > > I just want practical solution. Now there are no tools to browse what > files > are used by applications. And simple convention could be good enough. I agree there's a need for a practical solution; however, our definitions of practical probably differs. To me, practical is along the lines of a) inspecting Path allInstances / searching for source hits on strings that seem to match what I'm looking for b) opening class references to FileLocator / Path + some scrolling/eyeballing The point is, this is the type of task you may do variations of 5-20 times during a single work day; if one has to rely on a) There being a convention b) You being aware of the convention c) The use you are interested in actually having followed the convention to accomplish each, I personally prefer getting creative in use of a few core tools*. That said, we do have a few ways to group methods across packages based on related functionality; 1) Method extensions on a central location (personally not a big fan, as you may have deduced) 2) Implementing a common trait (Seems a bit heavyweight for this though) 3) Annotations/pragmas/method tags/whatever you want to call them.* 4) ? Cheers, Henry *A generic annotations explorer (with dropdown / autocompletion of known annotations, and filtering on the different arg values) would be a core tool I'd be interested in using. It could also act as a driver for adhering to said convention of method tags for cross-package categorization, not just for methods specifying file names, but in other areas as well. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 3, 2017