November 2015 - Pharo-users

Re: [Pharo-users] #storeOn: question

by stepharo

Wait :) Help us :) It would be good to check who is using that and evaluate if we can remove it. Stef Le 30/11/15 15:29, Werner Kassens a Ã©crit : > Hi Sven, > i see, then i'll simply forget it (i asked, because i halfway expected > that). thanks for that info. > werner > > On 11/30/2015 03:23 PM, Sven Van Caekenberghe wrote: >> I am not so sure the #storeOn: / #readFrom: mechanism is still being >> maintained. I am not using it in any case, I thought it was mostly >> broken. I would be surprised if someone is still using it for real. >> >> But I might be wrong. In that case there should be a suite of real >> unit tests that defines and maintains the expected behaviour. And >> then you would be right, we should fix it. >> >> Sven >> > >

Nov. 30, 2015

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

by stepharo

Why could not I publish code to a fossil repo using the same "conceptual" commands than git? Same question for Mercurial. So we are talking about abstraction over low-level APIs. Basic engineering practices. This is what we are doing with Athens (do not expose Cairo to the complete system) OSwindow (do not expose SDL to the complete system). Pharo is not done (but people could do that but when I see that peopel were forced to reverse engineer the git protocol) to script git at least this is not our objectives. Our objectives of the mail I sent and the answers of christophe are - make sure that we can version our code - without be tight to a back-end Stef

Nov. 30, 2015

Pharo productivity

by phil＠highoctane.be

I have been using Pharo somewhat less in my current projects. Nevertheless, I needed a tool done fast and behaving correctly. Did it the TDD way with Pharo. Great experience. Great productivity. No messing around with external libraries, modules... 64-bit Linux compatibility would really help these days. But stuffing Pharo and 32 bit on a docker container works nicely too. Phil

Nov. 30, 2015

Re: [Pharo-users] Basic versioning of GitHub repositories from within Pharo

by stepharo

+ 1 It is about abstraction. Le 30/11/15 10:06, Christophe Demarey a Ã©crit : > Hi, > > Le 29 nov. 2015 Ã 20:00, Dimitris Chloupis a Ã©crit : > >> And there lies the trap. >> >> If you end up making something that works with everything, you will >> create something that just works with everything instead of something >> that works very well with one thing. > > could be. But we do not want to plug everything. Just having the door > opened for the next cool VCS. > Even if is only used for git it is good to have a Pharo API that is > not the GIT API. We do not want git calls mixed everywhere. We want a > clean and clear API for versioning. > This API also prevents you from git API changes. You will only have > one place to update and so on. > >> Right now Git is by very far the undisputed king of version control >> and has completely dethroned SVN. > > King because widely used but other are also as valuable if not more. > >> Ironically the things that make git integration in pharo so hard is >> all the thing that are there to decouple it from git , like filetree >> metadata , or continuous support for mcz and monticello. > > I do not agree on this point. There is no VCS interoperability layer > in Pharo. Tools are directly manipulating Monticello. > >> In the end you cant have your cake and eat it too. We will have to >> choose between very good integration with git or average / mediocre >> integration with multiple backends. > > again, I cannot agree. It is a bad idea to have calls to an external > tool / library wide spread in the image. We need our own API. It is > particularly true for git that has an API mixing daily tasks with > other power admin commands (rewrite of the history with possible code > loss). > I do not think we need full support of git in the image, i.e. > supporting all commands and options, but only what is needed to do > correct versioning from Pharo (special git commands can still be done > with command-line). > >> >> On Sun, Nov 29, 2015 at 8:15 PM stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> What I would like for Pharo is to avoid to be bound to a given >> back-end >> for its versionning. >> This master is a step in the right direction >> >> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_… >> >> Stef >> >> >

Nov. 30, 2015

Re: [Pharo-users] [ANN] breakpoints and watchpoints working

by Marcus Denker

> >>> but a problem you could be aware is setting a break once in InputEventFetcher>>signalEvent: , and then moving the mouse, the image hangs. >>> >> Thanks, we will investigate. The âonceâ breakpoint triggers a recompile before opening the debugger. >> but of course the devil is in the detailsâ¦ we will check to see what exactly is happening here. >> > > I think I understand what happens: the method is called because there is an interrupt. Check for interrupt happens on all message sends > ==> even though we *want* to recompile before calling the method again, the check for interrupt happens and it is called again before the new > method is installed. Hmm.. I think it could be fixed by changing priorities of running threads: if we lover (temporarily) the input-event fetcher priority and raise the thread that does the compiling/installing, maybe we can make sure that the signalEvent: is not called before the break is removedâ¦ Marcus

Nov. 30, 2015

Re: [Pharo-users] PharoJS Status

by craig

I just loaded PharoJS into a fresh v5 image, Â and I also had the DNU message until I loaded theÂ NewExternalWebBrowser package.Â Craig Sent from Samsung Mobile -------- Original message -------- From: Noury Bouraqadi <bouraqadi(a)gmail.com> Date:2015/11/30 5:48 PM (GMT+02:00) To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] PharoJS Status Just tested with a fresh image and it worked. Noury On 30 Nov 2015, at 16:37, Andy Burnett <andy.burnett(a)knowinnovation.com> wrote: >>> Craig said Hi All, I'd like to start messing around with PharoJS.Â Can anybody tell what the status is?Â (Stable, broken, etc.) And, which Pharo version should I use for this? <<< I have just started playing with it. I have had some difficulty getting a running image. Following the instructions - should - work, but I found that I needed to install the NewExternalWebBrowser package separately before it would run. Cheers Andy

Nov. 30, 2015

Re: [Pharo-users] Sharing data between images

by Dimitris Chloupis

ah ok, now its clear :) On Mon, Nov 30, 2015 at 8:48 PM Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > I do, but I have not made them diff friendly, because I store "documents" > on them, so is easy to have long lines inside them that are treated as > binaries in my DVCS (fossil). Sven have told me some approaches to deal > with this, but I haven't had the time to explore them. > > Cheers, > > Offray > > > On 30/11/15 12:37, Dimitris Chloupis wrote: > > you wanna version control your STON files ? sound reasonable. > > On Mon, Nov 30, 2015 at 6:56 PM Offray Vladimir Luna CÃ¡rdenas < > offray(a)riseup.net> wrote: > >> Hi, >> >> I'm using STON, precisely for its textual nature, because for >> collaborative writing it would be nice to have a diff friendly storage >> format. Still I haven't had the time to make my ston grafoscopio >> notebooks diff friendly when long lines appear (they're treated by >> fossil as binaries) but seems not to difficult to do (is mostly about >> having time to play with it). >> >> Cheers, >> >> Offray >> >> On 29/11/15 10:56, Sven Van Caekenberghe wrote: >> > Fuel is binary, faster and store more special kinds of objects. STON is >> textual, you can read and edit it, better suited for model objects. >> > >> >> On 29 Nov 2015, at 16:35, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> >> >> >> Hi, >> >> >> >> have a look at Fuel, Itâs included in the image. See >> http://files.pharo.org/books/enterprisepharo/book/Fuel/Fuel.html for >> more info. >> >> >> >>> On Nov 29, 2015, at 11:57, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >>> >> >>> Just wondering what my options are about sharing data between images, >> should I use Ston ? A database ? something else ? >> >>> >> >>> I would prefer options that have as few dependencies as possible and >> something that does not require from my users to install external stuff. >> >>> >> >>> For now Ston looks like a good option but I am very new to all this >> so I would welcome any advice from the pharo experts. >> >> >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> >> >> Johan Fabry - http://pleiad.cl/~jfabry >> >> PLEIAD and RyCh labs - Computer Science Department (DCC) - >> University of Chile >> >> >> > >> > >> >> >> >

Nov. 30, 2015

Re: [Pharo-users] [ANN] breakpoints and watchpoints working

by Marcus Denker

> On 28 Nov 2015, at 08:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >> Is there a way to query all breakpoints like a query of senders of #halt? > > you can search for the senders of #break. > > But as class Breakpoint has a list of all active breakpoints, we add a browseAll method there > easily. > browseAll <script> | methods | methods := AllBreakpoints flatCollect: [ :breakpoint | breakpoint link methods ]. Smalltalk tools messageList browse: methods This will be added the next time we can do an update again (CI is in a strange state) >> but a problem you could be aware is setting a break once in InputEventFetcher>>signalEvent: , and then moving the mouse, the image hangs. >> > Thanks, we will investigate. The âonceâ breakpoint triggers a recompile before opening the debugger. > but of course the devil is in the detailsâ¦ we will check to see what exactly is happening here. > I think I understand what happens: the method is called because there is an interrupt. Check for interrupt happens on all message sends ==> even though we *want* to recompile before calling the method again, the check for interrupt happens and it is called again before the new method is installed. Marcus

Nov. 30, 2015

Re: [Pharo-users] Sharing data between images

by Offray Vladimir Luna CÃ¡rdenas

I do, but I have not made them diff friendly, because I store "documents" on them, so is easy to have long lines inside them that are treated as binaries in my DVCS (fossil). Sven have told me some approaches to deal with this, but I haven't had the time to explore them. Cheers, Offray On 30/11/15 12:37, Dimitris Chloupis wrote: > you wanna version control your STON files ? sound reasonable. > > On Mon, Nov 30, 2015 at 6:56 PM Offray Vladimir Luna CÃ¡rdenas > <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: > > Hi, > > I'm using STON, precisely for its textual nature, because for > collaborative writing it would be nice to have a diff friendly storage > format. Still I haven't had the time to make my ston grafoscopio > notebooks diff friendly when long lines appear (they're treated by > fossil as binaries) but seems not to difficult to do (is mostly about > having time to play with it). > > Cheers, > > Offray > > On 29/11/15 10:56, Sven Van Caekenberghe wrote: > > Fuel is binary, faster and store more special kinds of objects. > STON is textual, you can read and edit it, better suited for model > objects. > > > >> On 29 Nov 2015, at 16:35, Johan Fabry <jfabry(a)dcc.uchile.cl > <mailto:jfabry@dcc.uchile.cl>> wrote: > >> > >> Hi, > >> > >> have a look at Fuel, Itâs included in the image. See > http://files.pharo.org/books/enterprisepharo/book/Fuel/Fuel.html > for more info. > >> > >>> On Nov 29, 2015, at 11:57, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > >>> > >>> Just wondering what my options are about sharing data between > images, should I use Ston ? A database ? something else ? > >>> > >>> I would prefer options that have as few dependencies as > possible and something that does not require from my users to > install external stuff. > >>> > >>> For now Ston looks like a good option but I am very new to all > this so I would welcome any advice from the pharo experts. > >> > >> > >> ---> Save our in-boxes! http://emailcharter.org <--- > >> > >> Johan Fabry - http://pleiad.cl/~jfabry > <http://pleiad.cl/%7Ejfabry> > >> PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile > >> > > > > > >

Nov. 30, 2015

Re: [Pharo-users] How fuel deals with circular reference ?

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 30/11/15 12:42, Dimitris Chloupis wrote: > ah this is very good news for me thanks. I really like Fuel, well done > guys, looks very well designed. > > Yeah feature wise I dont care about something advanced, If I need > something much more advanced I will use a proper database. > > I am slightly surprised that none or at least AFAIK has not create a > lightweight database API based on Fuel . Something similar to SQLite. > > https://www.sqlite.org/ > If you like sqlite, you should take a look to: [1] and [2] [1] http://fossil-scm.org/ [2] http://fossil-scm.org/index.html/doc/trunk/www/quotes.wiki > About scale, I guess I can brake things to multiple files. On other > thread someone mention that STON is a good choice for version control > but that is not a problem for me either since Git can handle binary > files like fuel files too. I made it. But I was not referring to the fact of store binaries in a DVCS (most of them can do it) but about diff-ing the STON file in a human and DVCS friendly way. Cheers, Offray

Nov. 30, 2015