August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] IceBerg and push for projects vs packages

by Nicolas Passerini

Well, I am not sure if this has to do with Iceberg itself, because Iceberg does nothing with dependencies. But I am not sure that a ConfigurationOfXXX really has information of only one package. Normally you will have only one configuration for each project, am I wrong? Then the configuration specifies (among other stuff) dependencies between the parts (packages) of your project... I think this is right. If you depend in another project, then you should not depend in specific packages but in another configuration. The problem here is that we are (at least Iceberg is) assuming a correlation between project and repository, because in fact Iceberg handles repositories. If a project would be spawn in several repositories, at least now Iceberg can't do anything about it, it will treat them as independent "projects". I am not sure about changing this logic in the near future, and also we should think if that is not a Cargo/Metacello feature. On Sat, Aug 27, 2016 at 10:35 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > one thing that I wanted to ask about IceBerg --- during the IceBerg talk > Nico mentioned that we need to think in terms of projects. > > Now I understand that perspective, because that's how git behaves and > that's how _I_ think, > > however at the same time, there is a strong push for focusing on > packages... having each package describing it's dependencies, etc. > > So my question is, how do those two views interact with each other? > Because I feel like they are going against each other. > > Peter > >

Aug. 29, 2016

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

by stepharo

This is a really nice and important question. I would really have a clear answer because it will make the system more stable. If you can build an analysis and let us know it would be really great. Something related but not on the same topic is that I would love to have a syntax for nested comments. This is really annoying to have to uncomment parts when we have to comment a large part. We discussed this back in 2007-2009 but we never did it. Stef Le 28/8/16 Ã 12:17, Nicolai Hess a Ã©crit : > Hi, > > where can I find a good reference about what characters are allowed as > binary selectors (from old syntax definition) and what is nowadays allowed > by the implementations. > > And whether the current set of allowed binaries selector includes some > additions on > purpose or if this is just a bug of the parser. > > From what I found out, (Blue book and some other smalltalk syntax > definitions) > the current set of allowed characters includes the "special characters": > $! $% $& $* $+ $, $- $/ $< $= $> $? $@ $\ $| $~ > (some implementation do not allow $@ and some calls $- not a special > character > but allowed as binary selector character) > > And this is what String>>#numArgs uses. Therefore > > '-' numArgs "->1". > '!' numArgs "->1". > And for example: > 'Â§' numArgs "-> -1 (the -1 is indicating "not even a valid selector")" > > But I am interested in the characters not called "special characters and > not even in the range 0-126. > > The scanner allowes much more characters to be used as a selector name > (From the scanners typeTable) : > > {Character value: 1 . Character value: 2 . Character value: 3 . > Character value: 4 . Character value: 5 . Character value: 6 . > Character value: 7 . Character backspace . Character value: 11 . > Character value: 14 . Character value: 15 . Character value: 16 . > Character value: 17 . Character value: 18 . Character value: 19 . > Character value: 20 . Character value: 21 . Character value: 22 . > Character value: 23 . Character value: 24 . Character value: 25 . > Character value: 26 . Character escape . Character value: 28 . > Character value: 29 . Character value: 30 . Character value: 31 . $! . > $% . $& . $* . $+ . $, . $- . $/ . $< . $= . $> . $? . $@ . $\ . $` . > $~ . Character delete . $â¬ . $ . $â . $Æ . $â . $â¦ . $â . $â¡ . $Ë . $â° > . $Å . $â¹ . $Å . $ . $Å½ . $ . $ . $â . $â . $â . $â . $â¢ . $â . $â . > $Ë . $â¢ . $Å¡ . $âº . $Å . $ . $Å¾ . $Å¸ . $ . $Â¡ . $Â¢ . $Â£ . $Â¤ . $Â¥ . > $Â¦ . $Â§ . $Â¨ . $Â© . $Â« . $Â¬ . $Â . $Â® . $Â¯ . $Â° . $Â± . $Â² . $Â³ . $Â´ . > $Â¶ . $Â· . $Â¸ . $Â¹ . $Â» . $Â¼ . $Â½ . $Â¾ . $Â¿ . $Ã . $Ã·} > > This means you can define a method with for example the name "Ã·". > > So , the question I want to ask. What do we want to allow as a binary > selector (character). > All that is nowadays "parseable" as binary selector, or only the set > of "special characters" > or something between both, and where to put this information, the > "this is an allowed binary > selector character" information? > > Thanks > Nicolai >

Aug. 29, 2016

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

by Tudor Girba

Hi Glenn, Thanks a lot for this experiment. Could you send us the code snippet so people can play with it? The question is if perhaps we can identify a slimmer announcement support so that people can choose depending on requirements (e.g. parallelism or not). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow" > On 28 Aug 2016, at 21:11, Glenn CavarlÃ© <glenn.cavarle(a)gmail.com> wrote: > > Hi all, > Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of > Announcer in Bloc. > I made some test cases in Bloc-Tests to compare performances between > Announcer and BlEventRegistry. > The result is that Announcer is at least 5x slower in all tested cases. > Bloc has only specific needs about event dispatching, the first one is the > efficiency during event propagation. > It may be interesting to investigate why Announcer is slower and also what > are the uncovered cases in BlEventRegistry. > So, i'm interested in continuing our discussion about that. > > Regards, > Glenn. > > > > ----- > Glenn CavarlÃ© > -- > View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 29, 2016

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

by Henrik Nergaard

Probably from the use of critical (mutex), the way #subscriptionsHandling: is done, and that Announcer is built for X number of announcers and Y number of subscribers, which means that each announcement the announcer has to filter and find the correct subscribers. ---- | ann a | ann := Announcer new. ann when: Announcement do: [ :e ]. a := Announcement new. [[ ann announce: a ] bench ] timeProfile ----- Other drawbacks to consider when using announcements: Memory overhead from the Announcer object and each subscription. Memory ownership, the announcement subscriptions will strongly reference the announcement target unless the announcement is weakly, which can lead to memory leakage especially if strong and weak subscriptions are mixed in certain situations (see the mailing list from around the release of Pharo 6). This also leads to code where the announcer is the one who owns the target (multiple times if there are different announcements), which makes understanding who references what etc.. much harder to understand. In many places the control/message flow, and the relationship between the different parts of a bigger object tends to become much more difficult to understand (For example Rubric). Announcer usage shines when there is a need for a common place that X objects can communicate Y messages to Z recipients without needing to know who sends what, or who wants to receive what (For example System Announcements). Communication when only one Object "A" announces to another Object(s) "B", is better implemented as A referencing B, then B implements the necessary methods needed for this communication. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Glenn CavarlÃ© Sent: Sunday, August 28, 2016 9:11 PM To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] About the non-use of Announcer in Bloc Hi all, Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. The result is that Announcer is at least 5x slower in all tested cases. Bloc has only specific needs about event dispatching, the first one is the efficiency during event propagation. It may be interesting to investigate why Announcer is slower and also what are the uncovered cases in BlEventRegistry. So, i'm interested in continuing our discussion about that. Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2016

About the non-use of Announcer in Bloc

by Glenn CavarlÃ©

Hi all, Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of Announcer in Bloc. I made some test cases in Bloc-Tests to compare performances between Announcer and BlEventRegistry. The result is that Announcer is at least 5x slower in all tested cases. Bloc has only specific needs about event dispatching, the first one is the efficiency during event propagation. It may be interesting to investigate why Announcer is slower and also what are the uncovered cases in BlEventRegistry. So, i'm interested in continuing our discussion about that. Regards, Glenn. ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2016

Re: [Pharo-dev] Iceberg: success and fail

by Serge Stinckwich

I wrote an issue here: https://github.com/npasserini/iceberg/issues/124 There are several PRs apparently than you can push Nicolas I guess: https://github.com/npasserini/iceberg/pulls Thank you for the good job. On Sat, Aug 27, 2016 at 12:06 AM, Nicolas Passerini <npasserini(a)gmail.com> wrote: > Thank you Serge, I will pay a look at it. > > On Fri, Aug 26, 2016 at 11:43 PM, <serge.stinckwich(a)gmail.com> wrote: >> >> >> >> EnvoyÃ© de mon iPhone >> >> Le 26 aoÃ»t 2016 Ã 23:34, Nicolas Passerini <npasserini(a)gmail.com> a Ã©crit >> : >> >> Sorry, I didn't understand how to reproduce the problem. I understand you >> tried to save a package to the Iceberg repository, is that right? >> How did you create your local repository? Did you already have a git >> repository in the same directory? >> >> >> This was an existing git repo on github but without any Pharo packages. I >> load my project from Smalltalk and try to add the packages with the Iceberg >> tool. >> >> >> (Yes, an error in the issue tracker will be appreciated, thanks!) >> >> >> I will do it later. >> >> >> On Fri, Aug 26, 2016 at 7:25 PM, Serge Stinckwich >> <serge.stinckwich(a)gmail.com> wrote: >>> >>> Hi all, >>> >>> I was able to do my first commit with Iceberg on github ! >>> So this is great. >>> >>> I'm trying now to move an existing project on SmalltalkHub on github. >>> I made a local repository and when I try a package in this repo, I >>> have the following error. >>> I can put the error report on Iceberg issue tracker if needed. >>> >>> -- >>> Serge Stinckwich >>> UCBN & UMI UMMISCO 209 (IRD/UPMC) >>> Every DSL ends up being Smalltalk >>> http://www.doesnotunderstand.org/ >> >> > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 28, 2016

Re: [Pharo-dev] looking into Pharo VM

by Esteban Lorenzano

> On 28 Aug 2016, at 15:38, Ben Coman <btc(a)openinworld.com> wrote: > > Peter, The plan seems to be [1] to make the OpenSmalltalkVM a submodule under the pharo-vm. > > Esteban, Is this still the current plan, and when will this be done? I can't see an osvm folder at [2] yet. Are the build instructions there still valid? Is there anything I can do to help? Yes, this is the plan. Transition will be done soon (â¢) A couple of weeks according to my plans, let's see how it goes :) Current work is in my fork, under "merge-with-osvm" branch :) Esteban > > cheers -ben > > [1] http://forum.world.st/The-code-in-the-src-folders-in-the-repository-td49021… > [2] https://github.com/pharo-project/pharo-vm > >> On Sun, Aug 28, 2016 at 9:12 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > Why you say so? It is maintained, and still the official pharo distribution. >> >> Because of this: >> <graph snipped> >> which coincided with the announcement of OpenSmalltalkVM... that's why I wasn't sure what is the mainline. (Or maybe you took a vacation, which is also an explanation :)... which reminds me that I should take a vacation. :/ ) >> >> > Now, thinking that "looking at it" and "fixing" will be a nice and easy (and quick) fix... Good luck with that :) >> >> Well considering I spent many-o-hours just trying to figure out why copy pasting wasn't working from Chrome, I make no illusions this will be quick or easy... but at least I will feel like I am trying to end my suffering... :) >> >>> On Sun, Aug 28, 2016 at 2:53 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> By the way first thing I would do is to remove FT2 plugin and see how it works >> >> I'll start with this, although there's the GrafPort (Cairo?) related crash too. >> >> Plus I want to figure out how I can get crash dump on Windows... >> >> Thanks! >> Peter >

Aug. 28, 2016

Re: [Pharo-dev] looking into Pharo VM

by Ben Coman

Peter, The plan seems to be [1] to make the OpenSmalltalkVM a submodule under the pharo-vm. Esteban, Is this still the current plan, and when will this be done? I can't see an osvm folder at [2] yet. Are the build instructions there still valid? Is there anything I can do to help? cheers -ben [1] http://forum.world.st/The-code-in-the-src-folders-in-the-repository-td49021… [2] https://github.com/pharo-project/pharo-vm On Sun, Aug 28, 2016 at 9:12 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Why you say so? It is maintained, and still the official pharo > distribution. > > Because of this: > <graph snipped> > which coincided with the announcement of OpenSmalltalkVM... that's why I > wasn't sure what is the mainline. (Or maybe you took a vacation, which is > also an explanation :)... which reminds me that I should take a vacation. > :/ ) > > > Now, thinking that "looking at it" and "fixing" will be a nice and easy > (and quick) fix... Good luck with that :) > > Well considering I spent many-o-hours just trying to figure out why copy > pasting wasn't working from Chrome, I make no illusions this will be quick > or easy... but at least I will feel like I am trying to end my suffering... > :) > > On Sun, Aug 28, 2016 at 2:53 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> By the way first thing I would do is to remove FT2 plugin and see how it >> works >> > > I'll start with this, although there's the GrafPort (Cairo?) related crash > too. > > Plus I want to figure out how I can get crash dump on Windows... > > Thanks! > Peter >

Aug. 28, 2016

Re: [Pharo-dev] About Pharo 60

by Torsten Bergmann

> what are the points you are working on and that would deserve more focus and help from the community? I once started with a refactored version of GetText, covered with tests and tools. Code status I reached so far is here: http://www.smalltalkhub.com/#!/~TorstenBergmann/Gettext Idea was to be lean, no dependency on Seaside or others and get a well documented easy to use I18N solution. This would open up the possibility for more internationalized Pharo image and Pharo based apps. Would be nice if this could be completed and become part of our infrastructure to get a wider audience and globally usable applications. Additionally I would like to see: - investigation in the Win Pharo VM for being able to run again as a Windows Service (as it was possible for Squeak) to be able to easily provide, deploy and administrate a web app on Windows - image size management under control (as Philip already suggested) - better support for REST based systems (as Philip already suggested) - modern "Material style" UI (as Philip already suggested) but additionally with better out of the box Spec support and examples for regular widgets (Accordion, draggable Toolbars, calendar widget, date/time picker, ...) - clear rules to not accept undocumented classes/packages in the image And a clear separation in packages between CORE/BASE stuff and TESTS on top. Because TEST are usually only for development and for production/deployment of an app TESTS usually should be thrown out. Christmas list would include: - 64 Bit support - an out of the box Pharo Pi VM + image on the website Bye T.

Aug. 28, 2016

Re: [Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

by Peter Uhnak

On Sat, Aug 27, 2016 at 08:24:32AM -0300, HernÃ¡n Morales Durand wrote: > Just checked and the download URL is working. > If you send me mirror URLs then I can update the configuration to support > multiple download locations. The University's whole website was down when I was trying to access it, now it's back online. Maybe it would be good to have it on GitHub? (which would also automatically provide https). Thanks, Peter

Aug. 28, 2016