- Pharo-users - lists.pharo.org

Re: [Pharo-users] The Grapher charting engine

by Tudor Girba

Hi Stef, On Sat, Mar 21, 2015 at 8:52 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 21/3/15 13:58, Tudor Girba a Ã©crit : > >> Hi, >> >> I fully agree with your API suggestions, but I do not quite understand >> why you say that it is because of the scripting that the API does not look >> like this. It's the opposite I think. >> >> When you "script" you want as succinct as possible (so, no moveBehind: >> and stuff). And you want to gradually add details and not be forced to >> specify them from the very beginning (so, good defaults). In fact, the rule >> of thumb that I argue for is that a good scripting (and in fact any API) >> interface is one that allows you to make a difference with any new line of >> code. That means that, ideally, we would want every line to be able to live >> on its own and not require another one. It's obviously not always possible, >> but I find it helps me when I grow an API. >> > > use the technique you want but to not dillute my point. I do not care how > you do it. > I care about having details away. > To me the feel that roassal gives me is that this is a tool to make demo to > impress audience > as to grow something, while I think that it could be a killer app with two > faces: > predefined compact api and a scripting way where you open the trunk and > build your own. A long script will not impress any audience. These are the same goals, not different. The idea of builders (Grapher is such a builder) is supposed to provide those levels (the basic engine can do everything, and the builder provides a more constrained higher level API). I fully agree that the current builders are not expressive enough. And I also agree that we need a dedicated effort to just making them more compact. We are fully in sync and I do not dilute your point, but I do not want to leave the impression that "scripting" is something bad, or secondary :). Cheers, Doru > > S. > > -- www.tudorgirba.com "Every thing has its own flow"

March 21, 2015

Re: [Pharo-users] The Grapher charting engine

by stepharo

Le 21/3/15 13:58, Tudor Girba a Ã©crit : > Hi, > > I fully agree with your API suggestions, but I do not quite understand > why you say that it is because of the scripting that the API does not > look like this. It's the opposite I think. > > When you "script" you want as succinct as possible (so, no moveBehind: > and stuff). And you want to gradually add details and not be forced to > specify them from the very beginning (so, good defaults). In fact, the > rule of thumb that I argue for is that a good scripting (and in fact > any API) interface is one that allows you to make a difference with > any new line of code. That means that, ideally, we would want every > line to be able to live on its own and not require another one. It's > obviously not always possible, but I find it helps me when I grow an API. use the technique you want but to not dillute my point. I do not care how you do it. I care about having details away. To me the feel that roassal gives me is that this is a tool to make demo to impress audience as to grow something, while I think that it could be a killer app with two faces: predefined compact api and a scripting way where you open the trunk and build your own. S.

March 21, 2015

Re: [Pharo-users] Git overriding repo load from different source

by Thierry Goubier

Hi Peter, I'm not sure how to answer all those cases (did I remember a conversation during PharoDays?). Can you elaborate on a) and the failure? Because I remember looking at the ability to override conflicts in Metacello by just saying: onConflict: [:ex | ex allow ] (for example: Metacello new baseline: 'Metacello'; repository: 'github://dalehenrich/metacello-work:master/repository'; onConflict: [:ex | ex allow]; load ) But, overall, for such a need, I would see two approaches: - a cache-type repository which overrides loads, as the MC package-cache is doing, based on package name and version (which is bad). - Metacello overrides, which may already exist but I'm not knowledgeable enough. Thierry Le 21/03/2015 14:41, Peter UhnÃ¡k a Ã©crit : > Hi, > > I'm trying to load local package over git one... > basically: > > Projects A and B. > A depends on B. > A loads B from its BaselineOfA, the reference points to github. > > Now I have also local copy of B git repository, and I would like to > either > a) Override the load of B with local B (so the packages will point to > local instead of remote). > Currently it fails on MetacelloRepositorySpec>>hasNoLoadConflicts: > because each (local and git) repo points to different place. > This would be useful if I want to make change to B AFTER the project B > is already loaded. > > b) Add all packages from B to local B repo (same as manually using "add > to package..." in Monticello Browser") > This will work only if both the repos have the same packages, so > probably not that useful. (i.e. no code differences) > > c) Override the GitHub B repository in the BaselineOfA BEFORE the > project is loaded. > This would require some mapping in Monticello browser, I've seen > something like "repositoryOverrides:" but I don't know how it works. > This would be useful if I knew beforehand that I want to make changes > also to B. > > So how would one go about this? Having option "c)" would be probably the > best; I can live without "a)". :) > > Any pointers appreciated, > Peter

March 21, 2015

Re: [Pharo-users] Pharo-Launcher Windows 8.1

by Alain Rastoul

Le 21/03/2015 14:08, stepharo a Ã©crit : > Nice idea! >> I think that we should have a Pharo-bugs mailing list that gets >> notified for each bug that is filled in fogbugz Yes that would be nice, when you look at bugs on fogbugz site, you do not always see that it is discussed in the list (lot of threads) -- Regards, Alain

March 21, 2015

Re: [Pharo-users] Git overriding repo load from different source

by Peter UhnÃ¡k

e) having separate baseline method which does not load github packages and expects that they are already loaded But since baseline only uses single method I don't see how this could be done.

March 21, 2015

Re: [Pharo-users] Git overriding repo load from different source

by Peter UhnÃ¡k

d) unload all B packages, remove B github repo, load B locally However currently I can only unload packages one at a time manually, instead of all related to a repo. Peter

March 21, 2015

Threadsafe orderedCollection

by stepharo

Hi guys I'm looking for a thread safe simple orderedcollection to be able to concurrent add:. We have atomicSharedQueue but it does not support access to a given element. Stef

March 21, 2015

Git overriding repo load from different source

by Peter UhnÃ¡k

Hi, I'm trying to load local package over git one... basically: Projects A and B. A depends on B. A loads B from its BaselineOfA, the reference points to github. Now I have also local copy of B git repository, and I would like to either a) Override the load of B with local B (so the packages will point to local instead of remote). Currently it fails on MetacelloRepositorySpec>>hasNoLoadConflicts: because each (local and git) repo points to different place. This would be useful if I want to make change to B AFTER the project B is already loaded. b) Add all packages from B to local B repo (same as manually using "add to package..." in Monticello Browser") This will work only if both the repos have the same packages, so probably not that useful. (i.e. no code differences) c) Override the GitHub B repository in the BaselineOfA BEFORE the project is loaded. This would require some mapping in Monticello browser, I've seen something like "repositoryOverrides:" but I don't know how it works. This would be useful if I knew beforehand that I want to make changes also to B. So how would one go about this? Having option "c)" would be probably the best; I can live without "a)". :) Any pointers appreciated, Peter

March 21, 2015

Re: [Pharo-users] [Pharo-dev] The Grapher charting engine

by Tudor Girba

Nice work. I will reply about improvements separately. Cheers. Doru On Fri, Mar 20, 2015 at 10:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Dear all, > > As many of you know, Grapher is a Ã¼ber-cool charting engine, part of > Roassal. > For people who do not know what Grapher is, here is a (compelling we hope) > example: > > Which is obtained by the following script: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | b colors points ds pts dec lb | > b := RTGrapher new. > colors := Array with: Color red with: Color blue. > points := OrderedCollection new. > > colors do: [ :c | > ds := RTStackedDataSet new. > pts := ((1 to: 100) collect: [ :i | 50 atRandom - 25 ]) cumsum. > points add: pts. > ds points: pts. > dec := RTDevVarDecorator new. > dec moveBehind; > desviation: 0.5; > color: (c alpha: 0.3); > points: pts. > ds connectUsing: (RTLine new color: (c alpha: 0.5); width: 1 ). > b add: ds. > b addDecorator: dec. > ]. > > b axisX; axisY. > b build. > > lb := RTLegendBuilder new. > lb view: b view. > colors doWithIndex: [ :c :i | > lb addColor: c text: 'Series ', i printString ]. > lb build. > b view @ RTZoomableView. > b view > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > In our grand vision of making Roassal the best visualizing engine of the > Universe (we also know to be modest time to time, but not today :-), > Grapher will play a very important role. We would like to stabilize Grapher > and make it sure it happily fits everybody needs. You can help on it: > > - When you are tempted to look at the dark side of the planet (this is > where R, JFreeChart, gnuplot, D3 and all their friends live), let us know. > We will make sure to make you are happy again. > > - Share your wishlist with us. We already have a long todo list, but your > opinion does matter and will take it seriously > > - we are open to contributions, which could be financial, bug fixe, > enhancement, or simply encouragement. > > I am very happy to be surrounded by very smart engineers. Your > encouragement are making them happy :-) > > Cheers, > Alexandre, in the name of the Object Profile Team > > NB: sorry for the cross-list posting, but this email is very important for > us, and for you we hope. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 21, 2015

Re: [Pharo-users] Pharo-Launcher Windows 8.1

by stepharo

Nice idea! > I think that we should have a Pharo-bugs mailing list that gets > notified for each bug that is filled in fogbugz > > 2015-03-21 4:54 GMT-03:00 kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>>: > > > Bottom line is that reporting a problem in the mailing list first > makes much more sense because > > a) Way more likely to get an answer > b) Avoid adding to the list on non existent bugs in fogbugz > c) Bring the bug if it really exists to the attention of more > people, hence increase that chance of the bug getting a fix. > d) Far easier to remind people of the bug later on by just bumping > on the thread which everyone on the list will get notified > compared to fogbugz that if you are not subscribed to a bug you > wont be notified. > > So yes definitely want to discourage people from starting from > fogbugz. Also personally I dont like fogbugz because its so isolated. > > On Sat, Mar 21, 2015 at 2:15 AM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > > > > > On Fri, Mar 20, 2015 at 7:04 PM, Sebastian Heidbrink > <sheidev(a)yahoo.de <mailto:sheidev@yahoo.de>> wrote: > > Hi, > > I recently mentioned issues with the installation of > the pharo-launcher on Windows 8.1 > > Turned out I just needed to download the > PharoV30.sources file and place into the installation > folder. > > Now everything seems fine. > > Is this also a topic for the pharo bug list, or is > there another place where I can mention this? > > Sebastian > > On Sat, Mar 21, 2015 at 1:46 AM, kilon alios > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > there is also an options in settings that downloads > and install sources for you automagically. > > This is the right place to report issues and if you > are 100% sure its a bug you can report it also in the > pharo fogbuz > > > > 100% is a bit strong and sounds a bit discouraging :). As > long as you can list the detailed steps reproduce the problem, > then its worth putting in fogbugz. However fogbugz has a lot > of old issues and sometimes a new issue is like a lost tree in > the forrest. Its generally beneficial if you socialise it on > the mail list as well. > > A good workflow is: > 1. Search fogbugz for similar issues. > 2. Ask on the mail list if its a known issue, or if you should > create a new one. List your steps to reproduce and ideally a > solution. > 3. Log a new issue on fogbugz, copying the mail list > discussion there. Paste the link back to the mail list thread. > > So in general: > * the mail list has a broader audience and gets a better triage > * fogbugz tracks history to ensure it doesn't get lost - and > nothing happens except what goes through the tracker. (btw, > set Project=Launcher) > > cheers -ben > > >

March 21, 2015