September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TextAttributes in source code or class comment?

by Nicolai Hess

2015-09-08 11:03 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > On Sat, Sep 5, 2015 at 1:10 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > The same for the ]lang[ tag (see issue 15750) > > Ok. But I still don't know how to add a url to a method's source code > or comment from the UI. > > I mean, people with a non-English keyboard can produce source code > with ]lang[, but how can I produce a ]style[ ? > Hi Martin, In squeak, you can open a "choose style" dialog (select some text and use shortcut cmd+6). This lets you choose a text color or text links. For example, this is working in the class comment editor too, you can open the comment for class Morph, select a word like "Rectangle" and put a link to that class definition. This style attributes are first only a part of the Text instance, but saving or file out the class definition will include this style attributes with the ]style[ tag. Writing the style code text is not supported in pharo anymore. Changing the style (color and text links) with cmd+6 does not work in Rubrics text components anymore. It is working with the old PluggableTextMorph (but only color attributes - no links). Reading Text with style attributes is still working in Pharo (only color and emphasis, no text links). For example, put this "styled" text in a Workspace and inspect it: 'Red Gree Blue! ]style[(3 1 4 1 4)f1cred;b,f1b,f1cgreen;b,f1b,f1cblue;b!' readStream nextChunkText > > MartÃn > > > > > 2015-09-05 12:06 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > >> > >> Hi all > >> > >> On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda < > eliot.miranda(a)gmail.com> > >> > wrote: > >> >> > >> >> On Sep 4, 2015, at 1:33 PM, stepharo <stepharo(a)free.fr> wrote: > >> >> > >> >> Nobody defines urls in method comment anymore. > >> >> > >> >> I do. Several places in the Cog JIT contain irks to specification > >> >> documents. I don't care how its implemented (providing it's > preserved > >> >> in > >> >> text, or maybe have the pretty-printer scan comments for http://. > But > >> >> it is > >> >> sad that we can't have hyperlinks in text. > >> >> > >> >> Look I know the implementation stinks, but it can be fixed. But if > the > >> >> functionality is lost the system is weakened. Instead of asking what > >> >> you > >> >> can get rid if why not ask what you can reimplement or enhance more > >> >> elegantly. > >> > > >> > Its a reasonable strategy to start the discussion at the extreme end > >> > and work back from there :) But if its being used we should think > >> > harder about it. What alternatives/workarounds are there? > >> > > >> > First just to clarify, the aim is to remove Text from the image for > >> > the boot-strap? > >> > >> Yes :) I heard that we want to do cut the dependency to Text-Core, so > >> I browsed how to do it. > >> > >> Ben, there is an explanation about ]style[ in the class comment of > >> RemoteString. > >> > >> Eliot, I didn't thought that somebody was using Text. In fact, I don't > >> know how to do it in Pharo... how do you do? > >> I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I > >> just tested filing-in the attached .st file and it doesn't work. I > >> guess the new CodeImporter replaced the ChangeRecord implementation, > >> and it raises an error when ]style[. > >> > >> MartÃn > >> > >> > >> > > >> > 1. Save the text internally as a string in the stream format and > >> > up-convert to Text only when its being displayed? But I guess these > >> > styles aren't restricted to just occurring in comments and maybe cause > >> > problem for compilation ?? > >> > > >> > 2. As a stepping stone, introduce a TextPlaceholder class within > >> > minimal interface required by compilation which simply strips out all > >> > styles when Text is missing from the Image. When Text is present it > >> > #becomes back to it. Maybe risks loosing styles editing is done on > >> > the raw-stream-format. Maybe any editor would show the raw ]style[ > >> > and the compiler asks for #source which strips styles out. > >> > > >> > 3. Introduce Pillar and convert across. What are the requirements? > >> > a. URLs > >> > b. Class/method links > >> > c. Would you expect that Pillar can only appear in comments? Or > >> > in-line with code? > >> > d. Colouring? > >> > ...? > >> > > >> > btw, I haven't come across this before. Can someone point me to some > >> > url & styled code where I can have a look at it > >> > > >> > cheers -ben > >> > > >> >> Christ you're even using minis paced fonts. It's like the dark > >> >> ages in there ;-) > >> >> > >> >> In addition would prefer to have an explicit syntax as in Pillar or > >> >> html to > >> >> represent > >> >> an hyperlink. We could have > >> >> *Class>>#method* when pillar is not loaded and else a nicer > >> >> representation. > >> >> ctrl-click on a class should jump on it already and we could map it > to > >> >> *Class>>#method* > >> >> > >> >> In class comments we should use pillar and get a real text renderer. > >> >> > >> >> > >> >> Hi Martin, > >> >> > >> >> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias <tinchodias(a)gmail.com> > >> >> wrote: > >> >>> > >> >>> Hi all, > >> >>> > >> >>> The source code of a method could be a Text, with TextAttributes. In > >> >>> such > >> >>> case, it will be written down to a stream with a "]style[" suffix. > >> >>> Through a > >> >>> special parsing, the system can reconstruct the original Text. I > think > >> >>> the > >> >>> use of Text in source code or class comments is discouraged, but I > >> >>> understand we kept support for some backward compatibility. Now, may > >> >>> be it's > >> >>> time to remove this feature. > >> >>> > >> >>> With Pablo, we looked for uses of ]style[ in the .sources and > .changes > >> >>> files of a new Pharo 5.0, and there are no real uses. It appears in > >> >>> some > >> >>> comments only, as examples. > >> >>> > >> >>> We tried to find past discussions about this feature, because we're > >> >>> sure > >> >>> there were, but we couldn't. > >> >>> > >> >>> So, the questions is: > >> >>> > >> >>> Can we remove support for text in source code or class comments > in > >> >>> Pharo 5.0? > >> >> > >> >> > >> >> IIUC, ]style[ also supports things like embedding URL links and > method > >> >> references in class comments. So I would request that it /not/ be > >> >> removed. > >> >> It is very useful to put clickable links in class comments. > >> >> > >> >>> > >> >>> > >> >>> I think I can propose a slice. > >> >>> > >> >>> Regards, > >> >>> MartÃn > >> >>> PS: I was trying to cut dependencies of Text-Core with > System-Changes > >> >>> and > >> >>> System-Changes. > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> _,,,^..^,,,_ > >> >> best, Eliot > >> >> > >> >> > >> > > > > > >

Sept. 8, 2015

Re: [Pharo-dev] ANSICompatibility package

by Jan Vrany

Hi, On Tue, 2015-09-08 at 12:04 +0200, H. Hirzel wrote: > Jan, > > have a look at > > http://wiki.squeak.org/squeak/3172 > > ca 2800 tests Thanks for this, I'll make a note... > > First thing to do would be to do an quick analysis of the porting > effort. > > The question is why do not need a ANSI compatibility package. > > Grease > http://www.smalltalkhub.com/#!/~Seaside/Grease11 > is also an issue to look into for creating portable code. > Well: "Grease enhances the ANSI Smalltalk standard. With only a few exceptions, we assume platforms are fully ANSI-compliant." So on Pharo, Grease would not help as, IIUC, Pharo is not and does now want to be, ANSI compliant. This means that ANSICompatibility is (will be) needed for Grease if Pharo keeps removing ANSI methods, right? > In the end the incompatible methods in Pharo are often not all that > many. > This means that what you mention as 'quick and dirty' is actually > quite a good approach: You test the Smalltalk platform you are using > for the availability of certain methods and act accordingly. Except it makes the code a lot less comprehensible... Anyway, problem solved :-) Jan > > > --Hannes > > On 9/8/15, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > > On Tue, 2015-09-08 at 12:04 +0800, Ben Coman wrote: > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > > > wrote: > > > > Hi, > > > > > > > > is there actually such a thing like ANSICompatibility package? > > > > (it has been mentioned here lately, but I cannot find it) > > > > > > > > Thanks, Jan > > > > > > > > > > I made it up for the purpose of discussion to see what interest > > > it > > > generated. > > > Should we start one ? > > > > Well, let's put it this way: if there would be one, I'd use it and > > even > > contribute adding missing stuff. But I certainly have no time to > > start > > yet another project, having way too much on my plate already. > > > > So `(passes respondsTo: #removeAtIndex:) ifTrue:[...]` would do it. > > Quick and dirty, but no time and desire to fight Pharo :-) > > > > Cheers, Jan > > > > > cheers -ben > > > > > > > >

Sept. 8, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Henrik Johansen

> On 08 Sep 2015, at 10:13 , Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 06-09-15 10:37, stepharo wrote: >> >> >> Le 5/9/15 22:42, Tudor Girba a Ã©crit : >>> +1. >>> >>> We already deprecated on:send:to:/on:do: and I think we should do the >>> same for the subscribe:send:to:. >> Thanks Doru. I thought the same. Because each time I read subscribe: my >> mind stops for about half or a second until I remember that this is >> the same as when: send: to: > > When looking at the implementation, it looks as if we should > replace all #when:send:to: by #subscribe:when:do:, not the other way > around. > > Where is this all coming from? > > Stephan > > > An attempt at compatibility. IIRC; the original VW Announcements use when:send:to: (polymorphic with the old event system), while Lukas' implementation from Seaside use(d/s) subscribe:when:do: My 2c; If you need to pick one over the other, choose when:send:to. Cheers, Henry

Sept. 8, 2015

Re: [Pharo-dev] ANSICompatibility package

by H. Hirzel

Jan, have a look at http://wiki.squeak.org/squeak/3172 ca 2800 tests First thing to do would be to do an quick analysis of the porting effort. The question is why do not need a ANSI compatibility package. Grease http://www.smalltalkhub.com/#!/~Seaside/Grease11 is also an issue to look into for creating portable code. In the end the incompatible methods in Pharo are often not all that many. This means that what you mention as 'quick and dirty' is actually quite a good approach: You test the Smalltalk platform you are using for the availability of certain methods and act accordingly. --Hannes On 9/8/15, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On Tue, 2015-09-08 at 12:04 +0800, Ben Coman wrote: >> On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> >> wrote: >> > Hi, >> > >> > is there actually such a thing like ANSICompatibility package? >> > (it has been mentioned here lately, but I cannot find it) >> > >> > Thanks, Jan >> > >> >> I made it up for the purpose of discussion to see what interest it >> generated. >> Should we start one ? > > Well, let's put it this way: if there would be one, I'd use it and even > contribute adding missing stuff. But I certainly have no time to start > yet another project, having way too much on my plate already. > > So `(passes respondsTo: #removeAtIndex:) ifTrue:[...]` would do it. > Quick and dirty, but no time and desire to fight Pharo :-) > > Cheers, Jan > >> cheers -ben >> > >

Sept. 8, 2015

Re: [Pharo-dev] TextAttributes in source code or class comment?

by Eliot Miranda

Hi Martin, Sent from my iPhone > On Sep 5, 2015, at 3:06 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi all > >> On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> On Sep 4, 2015, at 1:33 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Nobody defines urls in method comment anymore. >>> >>> I do. Several places in the Cog JIT contain irks to specification >>> documents. I don't care how its implemented (providing it's preserved in >>> text, or maybe have the pretty-printer scan comments for http://. But it is >>> sad that we can't have hyperlinks in text. >>> >>> Look I know the implementation stinks, but it can be fixed. But if the >>> functionality is lost the system is weakened. Instead of asking what you >>> can get rid if why not ask what you can reimplement or enhance more >>> elegantly. >> >> Its a reasonable strategy to start the discussion at the extreme end >> and work back from there :) But if its being used we should think >> harder about it. What alternatives/workarounds are there? >> >> First just to clarify, the aim is to remove Text from the image for >> the boot-strap? > > Yes :) I heard that we want to do cut the dependency to Text-Core, so > I browsed how to do it. > > Ben, there is an explanation about ]style[ in the class comment of RemoteString. > > Eliot, I didn't thought that somebody was using Text. In fact, I don't > know how to do it in Pharo... how do you do? I develop the VM in Squeak. There's a menu pick in the squeak text editor that lets you do it. In the hierarchy of emphasis types there's a class called something like TextURL. I'll take a look soon and check. > I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I > just tested filing-in the attached .st file and it doesn't work. I > guess the new CodeImporter replaced the ChangeRecord implementation, > and it raises an error when ]style[. > > MartÃn > > >> >> 1. Save the text internally as a string in the stream format and >> up-convert to Text only when its being displayed? But I guess these >> styles aren't restricted to just occurring in comments and maybe cause >> problem for compilation ?? >> >> 2. As a stepping stone, introduce a TextPlaceholder class within >> minimal interface required by compilation which simply strips out all >> styles when Text is missing from the Image. When Text is present it >> #becomes back to it. Maybe risks loosing styles editing is done on >> the raw-stream-format. Maybe any editor would show the raw ]style[ >> and the compiler asks for #source which strips styles out. >> >> 3. Introduce Pillar and convert across. What are the requirements? >> a. URLs >> b. Class/method links >> c. Would you expect that Pillar can only appear in comments? Or >> in-line with code? >> d. Colouring? >> ...? >> >> btw, I haven't come across this before. Can someone point me to some >> url & styled code where I can have a look at it >> >> cheers -ben >> >>> Christ you're even using minis paced fonts. It's like the dark >>> ages in there ;-) >>> >>> In addition would prefer to have an explicit syntax as in Pillar or html to >>> represent >>> an hyperlink. We could have >>> *Class>>#method* when pillar is not loaded and else a nicer >>> representation. >>> ctrl-click on a class should jump on it already and we could map it to >>> *Class>>#method* >>> >>> In class comments we should use pillar and get a real text renderer. >>> >>> >>> Hi Martin, >>> >>>> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >>>> >>>> Hi all, >>>> >>>> The source code of a method could be a Text, with TextAttributes. In such >>>> case, it will be written down to a stream with a "]style[" suffix. Through a >>>> special parsing, the system can reconstruct the original Text. I think the >>>> use of Text in source code or class comments is discouraged, but I >>>> understand we kept support for some backward compatibility. Now, may be it's >>>> time to remove this feature. >>>> >>>> With Pablo, we looked for uses of ]style[ in the .sources and .changes >>>> files of a new Pharo 5.0, and there are no real uses. It appears in some >>>> comments only, as examples. >>>> >>>> We tried to find past discussions about this feature, because we're sure >>>> there were, but we couldn't. >>>> >>>> So, the questions is: >>>> >>>> Can we remove support for text in source code or class comments in >>>> Pharo 5.0? >>> >>> >>> IIUC, ]style[ also supports things like embedding URL links and method >>> references in class comments. So I would request that it /not/ be removed. >>> It is very useful to put clickable links in class comments. >>> >>>> >>>> >>>> I think I can propose a slice. >>>> >>>> Regards, >>>> MartÃn >>>> PS: I was trying to cut dependencies of Text-Core with System-Changes and >>>> System-Changes. >>> >>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot > <HelpOnHelp class-example.st>

Sept. 8, 2015

Re: [Pharo-dev] TextAttributes in source code or class comment?

by Martin Dias

On Sat, Sep 5, 2015 at 1:10 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > The same for the ]lang[ tag (see issue 15750) Ok. But I still don't know how to add a url to a method's source code or comment from the UI. I mean, people with a non-English keyboard can produce source code with ]lang[, but how can I produce a ]style[ ? MartÃn > > 2015-09-05 12:06 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: >> >> Hi all >> >> On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >> > On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >> > wrote: >> >> >> >> On Sep 4, 2015, at 1:33 PM, stepharo <stepharo(a)free.fr> wrote: >> >> >> >> Nobody defines urls in method comment anymore. >> >> >> >> I do. Several places in the Cog JIT contain irks to specification >> >> documents. I don't care how its implemented (providing it's preserved >> >> in >> >> text, or maybe have the pretty-printer scan comments for http://. But >> >> it is >> >> sad that we can't have hyperlinks in text. >> >> >> >> Look I know the implementation stinks, but it can be fixed. But if the >> >> functionality is lost the system is weakened. Instead of asking what >> >> you >> >> can get rid if why not ask what you can reimplement or enhance more >> >> elegantly. >> > >> > Its a reasonable strategy to start the discussion at the extreme end >> > and work back from there :) But if its being used we should think >> > harder about it. What alternatives/workarounds are there? >> > >> > First just to clarify, the aim is to remove Text from the image for >> > the boot-strap? >> >> Yes :) I heard that we want to do cut the dependency to Text-Core, so >> I browsed how to do it. >> >> Ben, there is an explanation about ]style[ in the class comment of >> RemoteString. >> >> Eliot, I didn't thought that somebody was using Text. In fact, I don't >> know how to do it in Pharo... how do you do? >> I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I >> just tested filing-in the attached .st file and it doesn't work. I >> guess the new CodeImporter replaced the ChangeRecord implementation, >> and it raises an error when ]style[. >> >> MartÃn >> >> >> > >> > 1. Save the text internally as a string in the stream format and >> > up-convert to Text only when its being displayed? But I guess these >> > styles aren't restricted to just occurring in comments and maybe cause >> > problem for compilation ?? >> > >> > 2. As a stepping stone, introduce a TextPlaceholder class within >> > minimal interface required by compilation which simply strips out all >> > styles when Text is missing from the Image. When Text is present it >> > #becomes back to it. Maybe risks loosing styles editing is done on >> > the raw-stream-format. Maybe any editor would show the raw ]style[ >> > and the compiler asks for #source which strips styles out. >> > >> > 3. Introduce Pillar and convert across. What are the requirements? >> > a. URLs >> > b. Class/method links >> > c. Would you expect that Pillar can only appear in comments? Or >> > in-line with code? >> > d. Colouring? >> > ...? >> > >> > btw, I haven't come across this before. Can someone point me to some >> > url & styled code where I can have a look at it >> > >> > cheers -ben >> > >> >> Christ you're even using minis paced fonts. It's like the dark >> >> ages in there ;-) >> >> >> >> In addition would prefer to have an explicit syntax as in Pillar or >> >> html to >> >> represent >> >> an hyperlink. We could have >> >> *Class>>#method* when pillar is not loaded and else a nicer >> >> representation. >> >> ctrl-click on a class should jump on it already and we could map it to >> >> *Class>>#method* >> >> >> >> In class comments we should use pillar and get a real text renderer. >> >> >> >> >> >> Hi Martin, >> >> >> >> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias <tinchodias(a)gmail.com> >> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> The source code of a method could be a Text, with TextAttributes. In >> >>> such >> >>> case, it will be written down to a stream with a "]style[" suffix. >> >>> Through a >> >>> special parsing, the system can reconstruct the original Text. I think >> >>> the >> >>> use of Text in source code or class comments is discouraged, but I >> >>> understand we kept support for some backward compatibility. Now, may >> >>> be it's >> >>> time to remove this feature. >> >>> >> >>> With Pablo, we looked for uses of ]style[ in the .sources and .changes >> >>> files of a new Pharo 5.0, and there are no real uses. It appears in >> >>> some >> >>> comments only, as examples. >> >>> >> >>> We tried to find past discussions about this feature, because we're >> >>> sure >> >>> there were, but we couldn't. >> >>> >> >>> So, the questions is: >> >>> >> >>> Can we remove support for text in source code or class comments in >> >>> Pharo 5.0? >> >> >> >> >> >> IIUC, ]style[ also supports things like embedding URL links and method >> >> references in class comments. So I would request that it /not/ be >> >> removed. >> >> It is very useful to put clickable links in class comments. >> >> >> >>> >> >>> >> >>> I think I can propose a slice. >> >>> >> >>> Regards, >> >>> MartÃn >> >>> PS: I was trying to cut dependencies of Text-Core with System-Changes >> >>> and >> >>> System-Changes. >> >> >> >> >> >> >> >> >> >> -- >> >> _,,,^..^,,,_ >> >> best, Eliot >> >> >> >> >> > > >

Sept. 8, 2015

Re: [Pharo-dev] ANSICompatibility package

by Jan Vrany

On Tue, 2015-09-08 at 12:04 +0800, Ben Coman wrote: > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > wrote: > > Hi, > > > > is there actually such a thing like ANSICompatibility package? > > (it has been mentioned here lately, but I cannot find it) > > > > Thanks, Jan > > > > I made it up for the purpose of discussion to see what interest it > generated. > Should we start one ? Well, let's put it this way: if there would be one, I'd use it and even contribute adding missing stuff. But I certainly have no time to start yet another project, having way too much on my plate already. So `(passes respondsTo: #removeAtIndex:) ifTrue:[...]` would do it. Quick and dirty, but no time and desire to fight Pharo :-) Cheers, Jan > cheers -ben >

Sept. 8, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Stephan Eggermont

On 06-09-15 10:37, stepharo wrote: > > > Le 5/9/15 22:42, Tudor Girba a Ã©crit : >> +1. >> >> We already deprecated on:send:to:/on:do: and I think we should do the >> same for the subscribe:send:to:. > Thanks Doru. I thought the same. Because each time I read subscribe: my > mind stops for about half or a second until I remember that this is > the same as when: send: to: When looking at the implementation, it looks as if we should replace all #when:send:to: by #subscribe:when:do:, not the other way around. Where is this all coming from? Stephan

Sept. 8, 2015

Re: [Pharo-dev] garbage on transcript

by Thierry Goubier

Hi Stef, yes, this is annoying. Thierry Le 08/09/2015 08:09, stepharo a Ã©crit : > Hi > > when I define methods and the Transcript is open I get such kind of > trace and I do not get where it comes from. > I think that this is the syntactical coloring. > Would be good to avoid because this is annoying. > > StoreImporter>>messageSelectorAndArgumentNames (statements is Undeclared) > > UndefinedObject>>noMethod (messageSelectorAndArgumentNames is Undeclared) > > Stef > >

Sept. 8, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 8, 2015