- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Binary selector and special characters

by Thierry Goubier

2016-08-31 20:55 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-08-31 17:31 GMT+02:00 John Brant <brant(a)refactoryworkers.com>: > >> On 08/31/2016 08:46 AM, Nicolai Hess wrote: >> >> Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner) >>> explicit allowes >>> "#($Â± $Â· $Ã $Ã·)" to be binary selector characters ? >>> >> >> I do -- I added them about 20 years ago :)... >> >> Is there any smalltalk dialect that uses these characters ? >>> >> >> VW allows them. When possible, we made the scanner/parser be a superset >> of the VW & VA syntax. >> >> >> John Brant >> >> > Thank you John, for the info. > Hm, now, what to do, fix our (pharo) parser to allowe these characters as > binary selectors or change the scanner to not > generate binary selector tokens for them... > I'd say change the parser to accept them. Thierry

Aug. 31, 2016

Re: [Pharo-dev] About Pharo 60

by Serge Stinckwich

On Wed, Aug 31, 2016 at 9:16 PM, stepharo <stepharo(a)free.fr> wrote: > In squeak by example > > we could tag in the document code snippet as text and a perl script > > turn the expression into Sunit method and run the tests > > We lost that. Yes I remember this was very nice. We should have a look to the org-babel env that I demonstrate shortly during the ESUG "show us your project" session. This based also on a markup language (org-mode) and you could use for doing literate programming: http://orgmode.org/worg/org-contrib/babel/ Some lessons should be extracted from that in order to enhance Pillar in this direction also. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 31, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by Sven Van Caekenberghe

You can also explicitly name your pages (tabs) by double-clicking the title and changing it. Then your pages get copied to play-stash using that name. This gives you more control over what happens. > On 31 Aug 2016, at 22:30, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > On Wed, Aug 31, 2016 at 10:10:21PM +0200, Tudor Girba wrote: >> Hi, >> >> The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? >> >> One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. >> >> As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. >> >> In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. >> >> What do you think? > > Thank you both for the answers, I didn't know there was a disk storage that was independent of what was shown to me, so next time I crash I will check. > But there were other strange issues going around, or at least confusing. So I'll try to play with it a bit tomorrow. > > Thanks, > Peter

Aug. 31, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by Peter Uhnak

On Wed, Aug 31, 2016 at 10:10:21PM +0200, Tudor Girba wrote: > Hi, > > The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? > > One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. > > As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. > > In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. > > What do you think? Thank you both for the answers, I didn't know there was a disk storage that was independent of what was shown to me, so next time I crash I will check. But there were other strange issues going around, or at least confusing. So I'll try to play with it a bit tomorrow. Thanks, Peter

Aug. 31, 2016

Re: [Pharo-dev] why is gt playground not saving the code

by Tudor Girba

Hi, The code should actually be saved on disk every time you type. Please take a look at the files from play-cache. Could you confirm? One bug is that the history is cached and not refreshed, so when you re-open a crashed page the image does not know that there is another file. This has to be changed. As for having the currently opened playgrounds in the dropdown, we chose it like that because when you open the dropdown you typically want to switch to something else than what exists right now in front of view. Thus showing the same entry again would provide little value. I believe that if we would solve the history bug described above, this issue would resolve itself as well. In any case, the dealing with the history of the playground is underdeveloped. So, letâs see if we can identify ways to improve the situation. What do you think? Cheers, Doru > On Aug 31, 2016, at 12:00 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > At this point Iâve lost cumulatively hours and hours of work due to Playground not saving the code; so every time I crash I lose. > > In the picture below the code was demonstrably executed and yet itâs not in the history and if I would crash (which happens several times a day in âstableâ pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical codeâ¦ > > <F091EED2725D4C679C390F5BC76E1CE3.png> > > Peter > <F091EED2725D4C679C390F5BC76E1CE3.png> -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

Aug. 31, 2016

Re: [Pharo-dev] About Pharo 60

by stepharo

In squeak by example we could tag in the document code snippet as text and a perl script turn the expression into Sunit method and run the tests We lost that. Stef Le 31/8/16 Ã 12:21, Peter Uhnak a Ã©crit : > On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote: >> Ok, now I know what I want. >> >> I want a better way to document. Because Iâm trying to write a documentation about my stuff, but there are too many disconnected ways to do that. Iâm trying to always have reasonable class comments. But sometimes you need a more general description, so you write help topics which are disconnected from class comments. Yes, we can add help topics generated from class comments but thatâs too weak. Additionally I version my projects on github, so I want t doc there in readme, or on a wiki. Whatâs more I think that itâs a good idea to export doc to the web. Because when someone mentioned package manifest I started to google for it and could not find anything. >> >> My suggestions: >> - write comments in pillar and slowly add pillar support to enrich comment (documentation) styles >> - add a possibility to reference classes/methods and help topics from pillar comments >> - have exporters to generate html documentation about a project based on comments and help topics >> - then I will be able to add a hook to Icebeg telling it: ok, on commit also generate a doc and export it as MarkDown (because we can) and commit it as a README or as a wiki entry or whatever. >> >> This way we will have interconnected documentation in the image, and if it should be placed somewhere else we export it. > +14. > > Knowing that I cannot verify that the documentation is sync with code is very discouraging to even start writing the docs. When I was writing a chapter for agile visualization, I had the examples as independent scripts which I could execute (I believe Pillar has added executable examples since then). > > But there are more things than examples, e.g. a Travis could run "docs verification" that would look at all the code (so even method and class name references) and made sure they exist and are not, say, deprecated. As Pillar provides you with a real syntax tree this might not be so hard. > > At least personally the above could be a real value for me with Pillar, because up until now it was just another document format (and there's a lot of better ones) with poor infrastructure. But deep integration with Pharo could make it really valuable, and we are getting there. > >> - then I will be able to add a hook to Icebeg telling it: ok, on commit also generate a doc and export it as MarkDown (because we can) and commit it as a README or as a wiki entry or whatever. > so close :) https://github.com/peteruhnak/IconFactory/blob/master/repository/BaselineOf… > > Peter > >

Aug. 31, 2016

Re: [Pharo-dev] Binary selector and special characters

by Nicolai Hess

2016-08-31 17:31 GMT+02:00 John Brant <brant(a)refactoryworkers.com>: > On 08/31/2016 08:46 AM, Nicolai Hess wrote: > > Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner) >> explicit allowes >> "#($Â± $Â· $Ã $Ã·)" to be binary selector characters ? >> > > I do -- I added them about 20 years ago :)... > > Is there any smalltalk dialect that uses these characters ? >> > > VW allows them. When possible, we made the scanner/parser be a superset of > the VW & VA syntax. > > > John Brant > > Thank you John, for the info. Hm, now, what to do, fix our (pharo) parser to allowe these characters as binary selectors or change the scanner to not generate binary selector tokens for them...

Aug. 31, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Thierry Goubier

2016-08-31 18:01 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 31 Aug 2016, at 10:10 , Glenn CavarlÃ© <glenn.cavarle(a)gmail.com> wrote: > > In Bloc the constraint is to propagate more than 2000 events/second without > to decrease fps > > > That's only a small part of the picture though, how many listeners are > there per each event? > And how large do you think the overhead specific to delivery guards is > compared to the constraint propagation handlers? > > On my machine (an old 2011 MBP), the following gives throughput on the > order of 300k-600k deliveries per second (very variable, due to the amount > of garbage generated from copying subs, I presume) > So close to 3 times the performance of entry-level celeron for laptops today (if I take the lowest of the 15" MBP of early 2011). > > #(1 10 100 1000) collect: [ :listeners | > > a := Announcer new. > b := Object new. > "Single message send in handler" > listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: > b.]. > "announcement creation overhead not included" > ann := Announcement new. > [a announce: ann] bench]. > > Cheers, > Henry > > And with a registry tuned for delivery, yet maintaining the guards > (attached)/exception/error handling properties, 900k -> 2.5M > > #(1 10 100 1000) collect: [ :listeners | > > a := Announcer new. > b := Object new. > a instVarNamed: 'registry' put: DeliveringSubscriptionRegistry new. > "Single message send in handler" > listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: > b.]. > "announcement creation overhead not included" > ann := Announcement new. > [a announce: ann] bench.]. > Thanks for the numbers. We need those to optimise what really matters :) Thierry

Aug. 31, 2016

Re: [Pharo-dev] About the non-use of Announcer in Bloc

by Henrik Johansen

> On 31 Aug 2016, at 10:10 , Glenn CavarlÃ© <glenn.cavarle(a)gmail.com> wrote: > > In Bloc the constraint is to propagate more than 2000 events/second without > to decrease fps That's only a small part of the picture though, how many listeners are there per each event? And how large do you think the overhead specific to delivery guards is compared to the constraint propagation handlers? On my machine (an old 2011 MBP), the following gives throughput on the order of 300k-600k deliveries per second (very variable, due to the amount of garbage generated from copying subs, I presume) #(1 10 100 1000) collect: [ :listeners | a := Announcer new. b := Object new. "Single message send in handler" listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: b.]. "announcement creation overhead not included" ann := Announcement new. [a announce: ann] bench]. Cheers, Henry And with a registry tuned for delivery, yet maintaining the guards (attached)/exception/error handling properties, 900k -> 2.5M #(1 10 100 1000) collect: [ :listeners | a := Announcer new. b := Object new. a instVarNamed: 'registry' put: DeliveringSubscriptionRegistry new. "Single message send in handler" listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: b.]. "announcement creation overhead not included" ann := Announcement new. [a announce: ann] bench.].

Aug. 31, 2016

Re: [Pharo-dev] Binary selector and special characters

by John Brant

On 08/31/2016 08:46 AM, Nicolai Hess wrote: > Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner) > explicit allowes > "#($Â± $Â· $Ã $Ã·)" to be binary selector characters ? I do -- I added them about 20 years ago :)... > Is there any smalltalk dialect that uses these characters ? VW allows them. When possible, we made the scanner/parser be a superset of the VW & VA syntax. John Brant

Aug. 31, 2016