April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Jira plugin for Monticello

by Camillo Bruni

I don't think that exists... On 2013-04-17, at 20:11, Max Leske <maxleske(a)gmail.com> wrote: > Hi guys > > Has anyone ever heard / used a Jira plugin for Monticello commits? Who would be interested in such a plugin? > > Cheers, > Max

April 17, 2013

Re: [Pharo-project] SPy VM

by Camillo Bruni

yes, I almost worked on it :P http://dl.acm.org/citation.cfm?id=1482373.1482382&coll=DL&dl=GUIDE&CFID=205… On 2013-04-17, at 18:05, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Did you know that there is smalltalk vm in PyPy? https://bitbucket.org/pypy/lang-smalltalk

April 17, 2013

[Pharo-project] Jira plugin for Monticello

by Max Leske

Hi guys Has anyone ever heard / used a Jira plugin for Monticello commits? Who would be interested in such a plugin? Cheers, Max

April 17, 2013

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

by stephane ducasse

we will do one for the next one. Now we need to kill bugs like mad. On Apr 17, 2013, at 5:02 PM, phil(a)highoctane.be wrote: > Why not make a doodle for this? > > > 2013/4/17 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > cool :) > > Ben > > On Apr 17, 2013, at 2:07 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> Marcus Denker-4 wrote >>> We are planning a sprint the 3rd of May: >> >> I want to join again via IRC/skype from NYC. It worked out well last time... >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Sprint-Sprint-Lille-May-3rd-tp4682097p4682106.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

April 17, 2013

Re: [Pharo-project] [update 2.0] #20599

by stephane ducasse

On Apr 17, 2013, at 1:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 17 Apr 2013, at 13:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> 20599 >> ----- >> >> 10297 Integrate 2.0: 10295 Zinc Update April 16th >> https://pharo.fogbugz.com/f/cases/10297 > > Hey Marcus, that is even cooler. I know it is a lot of manual manipulation work, so thanks again. > > If I can make this process easier, please let me know. > > I don't know what the policy is, but one solution could be to use ConfigurationOfZincHTTPComponents. One of these days we will get there :) > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

April 17, 2013

Re: [Pharo-project] the fun theory

by stephane ducasse

excellent! Yes we should make pharo a fun theory :) Stef On Apr 16, 2013, at 8:36 PM, Johan Brichau <johan(a)inceptive.be> wrote: > When I saw this website, I immediately thought about Pharo > > http://www.thefuntheory.com > "This site is dedicated to the thought that something as simple as fun is the easiest way to change peopleâs behaviour for the better." > > Keep having fun! > > Johan

April 17, 2013

Re: [Pharo-project] [Metacello] FTP repo without storing username/pass in ConfigurationOf

by Mariano Martinez Peck

On Tue, Apr 16, 2013 at 6:13 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Mariano, > > repositorOverrides: does apply to the entire load sequence, so it's not > the best option for trying to simply keep your credentials private ... > > OK. > The http repository does not expose user names and works just fine picking > up the image based instance with credentials defined so I would expect the > ftp repository to behave similarly. > +9999 > > If you want to keep the ftp user private the long term answer is submit a > bug against the ftp repository implementation and ask that ftp repositories > behave the same as http repositories with respect to credentials. > +1 > > Like I said before, I don't think that Metacello should be in the business > of managing credentials and that includes adding features to Metacello > whose sole purpose is to make up for a deficiencies elsewhere in the system > ... > > For the short term, you might just change the definition of > MCFtpRepository>>description from: > > description > ^ 'ftp://', user, '@', host, '/', directory > > to: > > description > ^ 'ftp://', host, '/', directory > > and your username can be kept private ... I doesn't appear that > description is used for anything other than display and comparison purposes > ... > > Yes, this is a very good idea. I will open an issue in the bug tracker. Anyone has an objection? Cheers, > Dale > > ----- Original Message ----- > | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > | To: metacello(a)googlegroups.com > | Sent: Tuesday, April 16, 2013 12:35:18 PM > | Subject: Re: [Metacello] FTP repo without storing username/pass in > ConfigurationOf > | > | On Tue, Apr 16, 2013 at 3:47 PM, Dale Henrichs <dhenrich(a)vmware.com> > wrote: > | > | > Mariano, > | > > | > After closer inspection it turns out that for FTP repositories, you > must > | > specify the username to uniquely identify the FTP url. If you specify > the > | > username and leave the password empty in your Metacello spec, things > should > | > work correctly ... > | > > | > > | Hi Dale, > | > | Thanks for the gory details, I understood :) > | Now I wonder...imagine I don't want to even include the username in the > | ConfigurationOf.... shouldn't the repository override trick work? > | Something along the lines of: > | > | | repository | > | repository := MCFtpRepository > | host: 'ftp.mydomain.com' > | directory: 'myDirectory' > | user: 'whatever' > | password: 'whatelse'. > | version := (ConfigurationOfXX project version: 'xxx'). > | version > | repositoryOverrides: Array with: repository. > | version load. > | > | just to be sure...#repositoryOverrides: does not propagate to transitive > | dependencies right? > | > | Thanks in advance, > | > | > | > | > | > | > Here are the gory details. > | > > | > There is code in Metacello that looks like the following: > | > > | > description := aSpec description. > | > (repo := repositories > | > detect: [:rep | rep description = description ] > | > ifNone: [ aSpec createRepository ]) ~~ nil > | > ifTrue: [ repos add: repo ] > | > > | > where Metacello is attempting to determine if the repository has > already > | > been created in the image. If the repository exists, then the in-image > | > credentials are used and you don't have to include user and password > in the > | > Metacello repository spec. > | > > | > BTW, if you look at MCRepository>>= Metacello is basically using the > same > | > algorithm. > | > > | > Now if you look at how MCHttpRepository behaves: > | > > | > (MCHttpRepository > | > location: 'http://example.com' > | > user: 'foo' > | > password: 'bar') description. > | > > | > prints as: > | > > | > 'http://example.com' > | > > | > Notice that the user is excluded from the description. > | > > | > Whereas for MCFtpRepository behaves differently: > | > > | > (MCFtpRepository > | > host: 'ftp.mydomain.com' > | > directory: 'myDirectory' > | > user: 'whatever' > | > password: 'whatelse') description. > | > > | > prints as: > | > > | > 'ftp://whatever@ftp.mydomain.com/myDirectory', > | > > | > Notice that the `user` is included in the description... > | > > | > So if you want an FTP repository to be considered #= to another FTP > | > repository you must specify the user name ... > | > > | > Let me know if this works for you. > | > > | > Dale > | > > | > ----- Original Message ----- > | > | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > | > | To: metacello(a)googlegroups.com > | > | Sent: Tuesday, April 16, 2013 7:55:50 AM > | > | Subject: Re: [Metacello] FTP repo without storing username/pass in > | > ConfigurationOf > | > | > | > | On Mon, Apr 15, 2013 at 10:14 PM, Dale Henrichs <dhenrich(a)vmware.com > > > | > wrote: > | > | > | > | > > | > | > > | > | > | > | > | > | > | > | > | > and set the username/password there, then Metacello should > honor > | > that > | > | > | > (like it does for the HTTP repository) ... so instead of adding > | > some > | > | > sort > | > | > | > of repository override to the load script, simply create the > FTP > | > | > repository > | > | > | > with username/password inline in your load script. > | > | > | > > | > | > | > | > | > | > | > | > | Do you mean that I should declare my FTP repository like: > | > | > | > | > | > | MCFtpRepository > | > | > | host: 'ftp.xxx.com' > | > | > | directory: 'mc' > | > | > | user: aUsername > | > | > | password: aPassword > | > | > | > | > | > | and somehow register that repo in Monticello ? so then when I > load a > | > | > | ConfiguratioOfMyApp that has that repo it will honor the already > set > | > up > | > | > | username/password? > | > | > > | > | > Yes. Metacello will use existing http/ftp/etc. repositories thus > | > | > inheriting the username and passwords set in the image. So if you > | > create > | > | > the ftp repository ahead of time (and specify a username and > password) > | > | > everything should work smoothly (barring any bugs in Metacello:) .. > | > | > > | > | > I think it is a good idea to try to keep Metacello out of the > | > | > username/password business as much as possible:) > | > | > > | > | > > | > | Hi Dale, I tried that but it still didn't work. I get the following > | > error: > | > | > | > | [:response | (TelnetProtocolError protocolInstance: self) > | > | signal: response] in FTPClient(TelnetProtocolClient)>>lookForCode: > | > | Receiver: a FTPClient > | > | Arguments and temporary variables: > | > | code: 331 > | > | response: '530 This is a private system - No anonymous login' > | > | > | > | > | > | In the baseline I have something like > | > | > | > | spec repository: 'ftp://ftp.mydomain.com/myDirectory'. > | > | > | > | > | > | and before loading with metacello I do: > | > | > | > | > | > | repository := MCFtpRepository > | > | host: 'ftp.mydomain.com' > | > | directory: 'myDirectory' > | > | user: 'whatever' > | > | password: 'whatelse'. > | > | > | > | MCRepositoryGroup default addRepository: repository. > | > | > | > | And in fact, if I open MonticelloBrowser I do see my FTP repo with > its > | > | correct username/pass...I can browse packages etc... > | > | > | > | So maybe I am not registering the package in the exact same > collection > | > | Metacello is looking for? where does it look for the repo? > | > | how does it "honor" the already set up username/pass? > | > | > | > | Thanks! > | > | > | > | > | > | > | > | > | > | > Dale > | > | > > | > | > -- > | > | > You received this message because you are subscribed to the Google > | > Groups > | > | > "Metacello" group. > | > | > To unsubscribe from this group and stop receiving emails from it, > send > | > an > | > | > email to metacello+unsubscribe(a)googlegroups.com. > | > | > For more options, visit https://groups.google.com/groups/opt_out. > | > | > > | > | > > | > | > > | > | > | > | > | > | -- > | > | Mariano > | > | http://marianopeck.wordpress.com > | > | > | > | -- > | > | You received this message because you are subscribed to the Google > Groups > | > | "Metacello" group. > | > | To unsubscribe from this group and stop receiving emails from it, > send an > | > | email to metacello+unsubscribe(a)googlegroups.com. > | > | For more options, visit https://groups.google.com/groups/opt_out. > | > | > | > | > | > | > | > > | > -- > | > You received this message because you are subscribed to the Google > Groups > | > "Metacello" group. > | > To unsubscribe from this group and stop receiving emails from it, send > an > | > email to metacello+unsubscribe(a)googlegroups.com. > | > For more options, visit https://groups.google.com/groups/opt_out. > | > > | > > | > > | > | > | -- > | Mariano > | http://marianopeck.wordpress.com > | > | -- > | You received this message because you are subscribed to the Google Groups > | "Metacello" group. > | To unsubscribe from this group and stop receiving emails from it, send an > | email to metacello+unsubscribe(a)googlegroups.com. > | For more options, visit https://groups.google.com/groups/opt_out. > | > | > | > > -- > You received this message because you are subscribed to the Google Groups > "Metacello" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to metacello+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Mariano http://marianopeck.wordpress.com

April 17, 2013

Re: [Pharo-project] [FWD] Options for Visualization

by Damir Majer

Hi Damien, Thanks for the Info, Cheers, Damir Damien Cassou wrote > On Wed, Apr 17, 2013 at 2:30 PM, Damir Majer < > damir@ > > wrote: >> IÂ´m searching for Options to visualize diagrams, for example an >> class-diagram. > > you may want to ask on the Moose-dev < > moose-dev@.unibe > > mailing > list as well. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill ----- -- Damir Majer ... be agile: www.majcon.de -- View this message in context: http://forum.world.st/FWD-Options-for-Visualization-tp4682108p4682159.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 17, 2013

Re: [Pharo-project] do you know what is this?

by Esteban Lorenzano

btw... as someone pointed here, I need to clarify something I said: I didn't mentioned Eliot because I was talking about the plugins... When we talk about the VM itself, the number of people who are capable of work on it reduces from 10 to maybe 5 (Eliot and some others like Igor... but certainly not me :) Disclaimer done... is so obvious for me that Eliot is "the master-guru" that I just forget to mention him (I'm really sorry for that). Esteban On Apr 17, 2013, at 6:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > you're right... I will cut&paste and write something extra next days :) > > On Apr 17, 2013, at 4:25 PM, phil(a)highoctane.be wrote: > >> Very interesting email, worth a post somewhere. >> >> >> 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> >> Hi, >> >> On Apr 17, 2013, at 11:23 AM, kilon <thekilon(a)yahoo.co.uk> wrote: >> >> > Anyway, my only objection is the fact that we will have twice the code to >> > maintain and more to worry about. >> >> let me explain this little thing a bit... >> >> Do you think that code doesn't need to be maintained and taken care how it is right now? >> >> I will draw you a picture of how it works this now >> >> /----------------------------------------------\ >> | "Pretended wonderland" (image) | >> =========================== >> | Lots of things: I/O, FFI, etc. | >> ----------------------------------------------- >> | Virtual Machine (Cog, Stack, Int) | >> \----------------------------------------------/ >> >> This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't? >> >> Well, wrong. >> >> Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). >> The difference is: >> >> - in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) >> - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. >> In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work). >> >> So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. >> As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work). >> >> Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. >> Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). >> This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance). >> >> So we need to change that. >> >> How to do it? There are two basic approaches possible: >> The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. >> As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all. >> >> Then it is our approach: move to the image all the things that can be moved. Then you will have this: >> >> /----------------------------------------------\ >> | "Pretended wonderland" | >> ----------------------------------------------- >> | Abstract system layer in image | >> | (that most of people will never | >> | see anyway) | >> =========================== >> | Virtual Machine (Cog, Stack, Int) | >> \----------------------------------------------/ >> >> With NativeBoost we can achieve same performance that we achieve using plain C. >> And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. >> And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) >> And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it. >> >> Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. >> And some times I feel that it is a power that the community is afraid to take :) >> >> lose your fear: having that power feels good :) >> >> And again: do you still think there is no need for maintain low level stuff? Think again. >> >> cheers, >> Esteban >> >> >> >

April 17, 2013

Re: [Pharo-project] do you know what is this?

by Esteban Lorenzano

you're right... I will cut&paste and write something extra next days :) On Apr 17, 2013, at 4:25 PM, phil(a)highoctane.be wrote: > Very interesting email, worth a post somewhere. > > > 2013/4/17 Esteban Lorenzano <estebanlm(a)gmail.com> > Hi, > > On Apr 17, 2013, at 11:23 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > > > Anyway, my only objection is the fact that we will have twice the code to > > maintain and more to worry about. > > let me explain this little thing a bit... > > Do you think that code doesn't need to be maintained and taken care how it is right now? > > I will draw you a picture of how it works this now > > /----------------------------------------------\ > | "Pretended wonderland" (image) | > =========================== > | Lots of things: I/O, FFI, etc. | > ----------------------------------------------- > | Virtual Machine (Cog, Stack, Int) | > \----------------------------------------------/ > > This is your world right now. You work on "pretended wonderland" side, assuming that everything below will work and hence you "don't need" to maintain what is below wonderland, isn't? > > Well, wrong. > > Everything need to be maintained. What you do not see too (you do not see it, but it is there, oh yes). > The difference is: > > - in wonderland, everybody can try to fix things (even id they fail, it is there to play/change/adapt) > - in levels below, there are just a few people on earth who actually can maintain that: Igor, myself and some others, but is for sure less than ten people. > In fact, what happens now is that I have to maintain not two, but three different versions of the same thing (for each platform), in two different languages (C and Objective-C) and three different sets of libraries. And yes, I "personalize" and use the "I" instead "we" because most of the times is me, with some really valuable from Igor and Camillo (but well, they do Athens and a PhD respectively, so many times is just a one-man-work). > > So, what actually happens now is that problems stack waiting for a solution, a solution which btw will never be of total satisfaction of users. > As an example, let's see the display plugin (which of course is not a plugin at all, if you remove that from vm, it stops to work). > > Display plugin is based in BitBlt, who creates/transforms bitmaps and renders them into screen. > Forget about 2D vectorial graphics (or any thing that can bebefict of using of GPU). > This technology is obsolete and retina displays on mac prove that: there is no way to do it work fine (that means: good rendering and good performance). > > So we need to change that. > > How to do it? There are two basic approaches possible: > The traditional one says that some "gurus" should write a new plugin (ideally backward compatible with the previous one). Then you have an updated plugin (and probably a perfect one, if you don't want to maintain it), until next time technology changes and then the gurus can be summoned again to do their magic. > As you can see, since our community of potential gurus is (with luck) ten persons in the world, that does not scales at all. > > Then it is our approach: move to the image all the things that can be moved. Then you will have this: > > /----------------------------------------------\ > | "Pretended wonderland" | > ----------------------------------------------- > | Abstract system layer in image | > | (that most of people will never | > | see anyway) | > =========================== > | Virtual Machine (Cog, Stack, Int) | > \----------------------------------------------/ > > With NativeBoost we can achieve same performance that we achieve using plain C. > And we have an incredible huge extra bonus: it is there so everybody can try to modify/fix/update if needed, not just the gurus. > And we also have much more advantages to show: this is moving also the low level programing to "pharo way", and as I showed in my silly videos, is bring the "immediate feedback" experience also to that level (something that you could never achieve with older way of thinking) > And finally... been in image does not need that you will need to deal with that. How many of you know of the internals of Zinc/Zodiac or the Weak Registry? (just to put a couple of examples). Most of us just take it and use it. > > Our path is to bring to the whole community the power to change everything in your environment. To change it live, in the pharo way. > And some times I feel that it is a power that the community is afraid to take :) > > lose your fear: having that power feels good :) > > And again: do you still think there is no need for maintain low level stuff? Think again. > > cheers, > Esteban > > >

April 17, 2013