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

Re: [Pharo-dev] Videos ESUG2014

by Marcus Denker

Thanks, I will add an extra playlist for IWST On 25 Aug 2014, at 22:19, Sebastian Tleye <stleye(a)gmail.com> wrote: > Mmm, strange, here are the links (I don't know if there are any missing) > > Understanding Pharo's global state to move program through time and space > > Live robot programming > > Toward a methodology to turm Smalltalk code to FPGA > > Towards agile cross-platform development > > The Moldable Inspector > > ClockSystem: Embedding Time in Smalltalk > > Reducing Waste in Expandable Collections: The Pharo Case > > > https://www.youtube.com/watch?v=vJOvU1V5hZ4&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=hwUOwpidp0A&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=XWHq4IQ7gIQ&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=OkDOiGZ8R1E&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=V4CVp77yhUo&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=AUZQemqQphg&list=UUO-vBhaKVZf0al-ISMMPvRw > > > > > 2014-08-25 22:13 GMT+02:00 Chris Cunningham <cunningham.cb(a)gmail.com>: > Naive response, but no, I don't see them on YouTube. > Nor at > http://www.esug.org/wiki/pier/Conferences/2014 > > > On Mon, Aug 25, 2014 at 1:06 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: > > > > 2014-08-25 1:39 GMT+02:00 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: > > Are the papers also available? > > Yeap, You don't see them? > > Cheers, > Javier > > > On Sat, Aug 23, 2014 at 8:03 AM, stepharo <stepharo(a)free.fr> wrote: > this is why you should put info in the slides :) > > > On 23/8/14 00:02, Igor Stasenko wrote: > Haha.. > my name (and voice) is now [written] recorded [in stone] on internet. > One step closer to world domination! :) > > Too bad, i was so dragged by presenting the stuff, that i forgot to give a credit to the guy, sitting next to me, who put a lot of effort to make Virtual CPU work. SHAME ON ME! :/ > His name is Max Mattone - remember his name! > And the list won't be complete without Clement Bera, who also contributed a lot to it as well. And many others in RMoD team. > > -- > Best regards, > Igor Stasenko. > > > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > >

Aug. 26, 2014

Re: [Pharo-dev] Videos ESUG2014

by Marcus Denker

On 25 Aug 2014, at 22:22, Sebastian Tleye <stleye(a)gmail.com> wrote: > Now, if you meant the paper but not the presentation, then I don't know where they are :-) > -> I will request all slides that are missing -> I will sync with the Student Volunteers for Videos -> Papers will be available, too. (I will check with the workshop organisers) > > 2014-08-25 22:19 GMT+02:00 Sebastian Tleye <stleye(a)gmail.com>: > Mmm, strange, here are the links (I don't know if there are any missing) > > Understanding Pharo's global state to move program through time and space > > Live robot programming > > Toward a methodology to turm Smalltalk code to FPGA > > Towards agile cross-platform development > > The Moldable Inspector > > ClockSystem: Embedding Time in Smalltalk > > Reducing Waste in Expandable Collections: The Pharo Case > > > https://www.youtube.com/watch?v=vJOvU1V5hZ4&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=hwUOwpidp0A&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=XWHq4IQ7gIQ&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=OkDOiGZ8R1E&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=V4CVp77yhUo&list=UUO-vBhaKVZf0al-ISMMPvRw > > https://www.youtube.com/watch?v=AUZQemqQphg&list=UUO-vBhaKVZf0al-ISMMPvRw > > > > > 2014-08-25 22:13 GMT+02:00 Chris Cunningham <cunningham.cb(a)gmail.com>: > > Naive response, but no, I don't see them on YouTube. > Nor at > http://www.esug.org/wiki/pier/Conferences/2014 > > > On Mon, Aug 25, 2014 at 1:06 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: > > > > 2014-08-25 1:39 GMT+02:00 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: > > Are the papers also available? > > Yeap, You don't see them? > > Cheers, > Javier > > > On Sat, Aug 23, 2014 at 8:03 AM, stepharo <stepharo(a)free.fr> wrote: > this is why you should put info in the slides :) > > > On 23/8/14 00:02, Igor Stasenko wrote: > Haha.. > my name (and voice) is now [written] recorded [in stone] on internet. > One step closer to world domination! :) > > Too bad, i was so dragged by presenting the stuff, that i forgot to give a credit to the guy, sitting next to me, who put a lot of effort to make Virtual CPU work. SHAME ON ME! :/ > His name is Max Mattone - remember his name! > And the list won't be complete without Clement Bera, who also contributed a lot to it as well. And many others in RMoD team. > > -- > Best regards, > Igor Stasenko. > > > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > > >

Aug. 26, 2014

Re: [Pharo-dev] Failing make a slice

by Marcus Denker

On 26 Aug 2014, at 00:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > A slice is nothing more than an empty mcz package with as requirements some other packages, namely the ones that you changed and want to include. I guess that if you take a fresh image and merge in your packages, you can create a new slice over them (provided they are dirty, sometimes this is a bit hard, you could make a trivial change). Make sure to save the slice with a higher version number. > The problem that the bug seems deeperâ¦ I have the impression that âSave Sliceâ does not search all the repos and if the number already exists, increase (like normal slice saving). Then, when saving, it *saves* the wrong version as it asks the cache âgive me name Xâ, and âname Xâ is already there, and it uses that for upload (or even skips the upload as the file is already there?). Even re-saving the slice does not help, as unchanged members are not re-saved with a new name. But even if this would work, everything fails as soon as you end up with two MCZ files with the same name (e.g. working in two images offline, or working on a package, save, but then only merge it *after* you did another change in the main branch that led to the same name). Maybe we should really add the hash in the filenameâ¦ Marcus > HTH > > On 25 Aug 2014, at 22:45, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > >> Is there a way to load the right packages and create a new slice? >> >> Thanks, >> Juraj >> >> On Aug 25, 2014, at 3:21 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> I'm really thinking that we should use a UUID in addition to author names to avoid such kind of problem. >>>> Hi, >>>> >>>> I have failed to make new slice for this issue: https://pharo.fogbugz.com/f/cases/13185/Move-embedded-fonts-from-Freetype-p… >>>> >>>> The last slice I have made depends on packages which has the same name but different UUID. >>>> >>>> How can I fix this? The issue should depend on FreeType-JurajKubelka.677, EmbeddedFreeType-JurajKubelka.3, EmbeddedFreeTypeTests-JurajKubelka.2. >>>> >>>> Thanks, >>>> Juraj >>>> >>> >>> >> >> > >

Aug. 26, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Voronyj Diagram

by Damien Pollet

Hi Natalia, I've been playing with it today, and look at the pretty pixels it makes :D The points are generated by the poisson disc sampling algorithm described at http://bost.ocks.org/mike/algorithms/ However, see the result of the doit, in redâ¦ the time grows really quick with the number of nodes, which makes it impractical with large point sets (the 2 smaller sets are instant, the 3rd one quickly pops the progress bar, and the 4th takes a couple minutes). Wikipedia says the complexity should be around N log N, so that's strange ; I've seen the code copies collections a lot, that might be itâ¦ but it's too late for coding now :| On 25 July 2014 19:12, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> wrote: > Thank you. > Yes, I will. > > Natalia > > On Jul 25, 2014, at 5:36 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > Impressive!!!! > > Natalia, will you be at esug? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Jul 25, 2014, at 8:10 AM, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> > wrote: > > Hello. > > I implemented Voronyj diagrams for Roassal. You can read about it here: > http://natalia.tymchuk.me/RTVoronyjDiagram/ . > I will be on vacation from Monday till Thursday, but it will be really cool > if you can write me your opinion about this project and all your remarks. > > Best regards, > Natalia > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 26, 2014

athens wrapper for (Form-)Canvas

by Nicolai Hess

I tried an alternative approach for rendering Morphs on athens without implementing drawOnAthensCanvas for every morph: 13866 <https://pharo.fogbugz.com/default.asp?13866> AthensFormCanvasWrapper still struggling with the text rendering. Yet I am not sure what is the better approach. Nicolai

Aug. 25, 2014

Re: [Pharo-dev] Failing make a slice

by Sven Van Caekenberghe

A slice is nothing more than an empty mcz package with as requirements some other packages, namely the ones that you changed and want to include. I guess that if you take a fresh image and merge in your packages, you can create a new slice over them (provided they are dirty, sometimes this is a bit hard, you could make a trivial change). Make sure to save the slice with a higher version number. HTH On 25 Aug 2014, at 22:45, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > Is there a way to load the right packages and create a new slice? > > Thanks, > Juraj > > On Aug 25, 2014, at 3:21 PM, stepharo <stepharo(a)free.fr> wrote: > >> I'm really thinking that we should use a UUID in addition to author names to avoid such kind of problem. >>> Hi, >>> >>> I have failed to make new slice for this issue: https://pharo.fogbugz.com/f/cases/13185/Move-embedded-fonts-from-Freetype-p… >>> >>> The last slice I have made depends on packages which has the same name but different UUID. >>> >>> How can I fix this? The issue should depend on FreeType-JurajKubelka.677, EmbeddedFreeType-JurajKubelka.3, EmbeddedFreeTypeTests-JurajKubelka.2. >>> >>> Thanks, >>> Juraj >>> >> >> > >

Aug. 25, 2014

Re: [Pharo-dev] Roadmap on tools?

by Nicolai Hess

2014-08-25 18:40 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > Hi! > > I have created the Nautilus roadmap > <https://github.com/pharo-project/pharo-workingRoadmaps> (in the pull > request <https://github.com/pharo-project/pharo-workingRoadmaps/pull/3>). > I have taken as a base the recent email of Nicolai Hess. > > If anyone wants to stress something important or give a link to a bug we > should consider, I appreciate it. You can write it here in the mainline > list or by changing the roadmap. > > Thanks, > Juraj > Great! Thank you. > > On Aug 24, 2014, at 2:01 AM, stepharo <stepharo(a)free.fr> wrote: > > > On 23/8/14 23:34, Juraj Kubelka wrote: > > Hi, > > I have found useful those roadmaps: > https://github.com/pharo-project/pharo-workingRoadmaps > Could it be possible to make one for the Pharo tools (e.g. Nautilus)? I > think there are people who have better idea what to make first and what > later. I would like to contribute on it and roadmap could help me. > > > Sure! > The point of the roadmap is really listing the feasible steps to improve > the system in a regular manner. > Create one for Nautilus. > - I would remove the bytecode and text icons (which are not consistent > with the instance access BTW) > - I would remove the history navigation > for example > > Now we will certainly add (but in a modular way) the GT-Inspector. But it > does not mean that we should not continue to improve the traditional tools. > > Stef > > > Thanks, > Juraj > > > > >

Aug. 25, 2014

Re: [Pharo-dev] Roadmap on tools?

by kilon alios

thats a normal reaction, the vast majority of people don't care about progress they care about money. They care about using products with large market share. This is why Apple releases information about its commercial success each semester. Progress is all about getting outside your comfort zone and doing the hard work sometimes driving yourself bankrupt (see Tesla) . So Pharo or Squeak in the end is for that minority of people who look for something really different and unique. If all you look is an language that is a variant of C or an IDE that is a variant of Visual Studion then neither Squeak or Pharo is for you and the fact you dislike the interface is just an excuse. I strongly disagree on Morphic, personally I love using it. It can be cleaner but still beats any other GUI I have used in terms of ease of use without sacrificing power. Spec on the other hand looks ugly to me , weird and very difficult to understand. But maybe its just my opinion and how my brain is wired. Afterall Spec has been very popular with Pharo devs so definitely is something I keep a close eye on . I really hope Morphic does not get removed, at least continue to be distributed as third party library.Though thats is unlikely with all the hard work of cleaning it up. Definetly there is room for a lot of libraries and alternatives, after all each person has different needs, preferences and goals. Personally I like seeing all this variation even if that means I wont be using most of it and there will be only of handful of tools I will be using. I love seeing people thinking outside the box and going for unexplored territory and I think Pharo as a platform is ideal for that. A roadmap is a very useful to have it helps the community get in sync and eliminates duplicate efforts. I am very interested into the Morphic cleanup and I may join the efforts too. On Tue, Aug 26, 2014 at 12:17 AM, Alain Rastoul <alr.dev(a)free.fr> wrote: > +1 for the GTInspector, and the Moose tools/paradigm too (Roassal, > Glamour, Moose and others), all that stuff is great step forward and could > arouse interest from doubtful people. > I remember myself failing to show some collegues at work how the smalltalk > system could be a cool tool to play with, even for people sticking on > dotNet, Delphi or C++. > And sometimes they remember that too ... > (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha > ...) > :( > Still working on that like a flea (?- a morpion) > > Morphic removed is good news - clumsy, buggy and weird - but I don't > understand the relationship with GTInspector ? > I googled about that and just found a post of you about Bloc in the > mailing list, it sounds like a good idea, and I'm sure you'll manage to do > it cleanly, but I'm also very curious about that: big bang or dependency > injection and small steps? other patterns, techniques ? a link on Bloc ? > I'm also curious about Spec and it's status after it's change to GPL ? > Will it be supported in the future ? What are the alternatives ? > > I understand that you are very busy, so no problem if there is no link on > existing material, I should survive, > just wait a little :) > > TIA > > > Regards > > Alain > > Le 24/08/2014 08:03, stepharo a Ã©crit : > > >> On 24/8/14 05:39, Alexandre Bergel wrote: >> >>> I see GTInspector as a big splash. I guess that if there would be a >>> Tool Roadmap, it would be focused on GTInspector. >>> >> >> Not necessarily. >> No time to explain sorry but else I would not improve morphic because >> bloc is coming and parallel actions are important. >> >> Stef >> > > > > >

Aug. 25, 2014

Re: [Pharo-dev] Faster ThreadSafeTranscript Re: [pharo-project/pharo-core] 06d05b: 40165

by Max Leske

I opened a case for removing ThreadSafeTranscript from the FLCommandlineHandler. Proposed slice is in inbox. Cheers, Max On 13.08.2014, at 19:17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Wed, Aug 13, 2014 at 8:24 AM, Ben Coman <btc(a)openinworld.com> wrote: > Eliot Miranda wrote: >> >> On Tue, Aug 12, 2014 at 5:27 AM, Ben Coman <btc(a)openinworld.com> wrote: >> GitHub wrote: >>> >>> Branch: refs/heads/4.0 >>> Home: https://github.com/pharo-project/pharo-core >>> Commit: 06d05bd822deee4a79736d9f99d4a666ca1637eb >>> https://github.com/pharo-project/pharo-core/commit/06d05bd822deee4a79736d9f… >>> Author: Jenkins Build Server <board(a)pharo-project.org> >>> Date: 2014-08-11 (Mon, 11 Aug 2014) >>> >>> >>> 13806 Remove ThreadSafeTranscriptPluggableTextMorph >>> https://pharo.fogbugz.com/f/cases/13806 >>> >>> >>> >> >> For anyone concerned about the performance of writing to Transcript from higher priority threads, just reporting that altering ThreadSafeTranscript to be safe for Morphic without ThreadSafeTranscriptPluggableTextMorph had a side effect of enhancing performance by 25x. With two runs of the following script... >> >> Smalltalk garbageCollect. >> Transcript open. "close after each run" >> [ Transcript crShow: ( >> [ >> | string | >> string := '-'. >> 1 to: 2000 do: >> [ :n | >> string := string , '-', n printString. >> Transcript show: string. >> ]. >> (Delay forMilliseconds: 10) wait. >> ]) timeToRun. >> ] forkAt: 41. >> >> >> >> Build 40162 reports timeToRun of 0:00:00:02.483 & 0:00:00:02.451 >> Build 40165 reports timeToRun of 0:00:00:00.037 & 0:00:00:00.099 >> >> >> Now I had meant to ask... I notice that FLFuelCommandLineHandler installs ThreadSafeTranscript, so I wonder it is affected by this change. Can some Fuel experts comment? >> >> >> Also I am looking for some advice for a minor downside I just noticed. The whole script above can complete between steps, so the entire output ends up in the PluggableTextMorph its size without being culled, which causes making a selection become really slow. Normally the excess text shown by Transcript is culled in half [1] by PluggableTextMorph>>appendEntry each time #changed: is called. >> >> PluggabletextMorph>>appendEntry >> "Append the text in the model's writeStream to the editable text. " >> textMorph asText size > model characterLimit ifTrue: "<---[0]" >> ["Knock off first half of text" >> self selectInvisiblyFrom: 1 to: textMorph asText size // 2. "<---[1]" >> self replaceSelectionWith: Text new]. >> self selectInvisiblyFrom: textMorph asText size + 1 to: textMorph asText size. >> self replaceSelectionWith: model contents asText. "<----[2]" >> self selectInvisiblyFrom: textMorph asText size + 1 to: textMorph asText size >> >> That works fine when #appendEntry is being called with lots of small changes, but for a single large change the entire change ends up in PluggableTextMorph via [2]. In this case >> model characterLimit "--> 20,000" [0] >> model contents size "--> 5,671,343" [2] >> where model == Transcript. >> >> So what is the behaviour you'd like to when too much is sent to Transcript? >> a. Show all content however briefly. >> b. Only the last 20,000 characters are put into the PluggableTextMorph, and the earlier data thrown away. >> I see a few ways to deal with this: >> 1. Limit the stream inside Transcript to a maximum 20,000 characters by basing it on some circular buffer. >> 2. Have "Transcript contents" return only the last 20,000 characters of its stream. >> 3. Limit to text sent to #replaceSelectionWith: [2] to 20,000 characters. >> >> Thoughts anyone? >> >> IMO 20,000 characters is way too little. I routinely set my limit to 200,000. So b) but with a higher limit. a) is pointlessly slow. > Thanks Eliot. Its good to know what is expected from Transcript. >> >> In your implementation list, surely 2. is the only thing that makes sense? > > I agree, (2.) would be efficient. It just would have been precluded if (a) was required. > >> If the limit can remain soft then anyone that wants to see more simply raises their limit. > > Do you mean you'd like Transcript characterLimit to be a Preference ? > > I'm not sure. If it was a preference I'd use it, but few others may find it useful. As I say, I need at east 20,000 chars on the transcript to effectively develop Cog; the VM simulator produces lots of output and realistically a transcript is the only convenient place to view it. So whether it was a preference ofr not I'd make sure the limit was >= 20k. > >> 1. & 3. are implementation details left up to you. > > I can do (1.) with Steph's new circular list. Doing (2.) means (3.) wont be required for this, but its probably beneficial so I'll log it as separate Issue. > >> As long as the transcript is reasonably fast and has the same protocol as WriteStream (it needs to support printOn: and storeOn: et al) implement it as you will. BTW, the Squeak transcript is appallingly slow. > -- > best, > Eliot

Aug. 25, 2014

Re: [Pharo-dev] Roadmap on tools?

by Alain Rastoul

+1 for the GTInspector, and the Moose tools/paradigm too (Roassal, Glamour, Moose and others), all that stuff is great step forward and could arouse interest from doubtful people. I remember myself failing to show some collegues at work how the smalltalk system could be a cool tool to play with, even for people sticking on dotNet, Delphi or C++. And sometimes they remember that too ... (Smalltalk? Squeak? -at that time- that blinking and poping toy ? hahaha ...) :( Still working on that like a flea (?- a morpion) Morphic removed is good news - clumsy, buggy and weird - but I don't understand the relationship with GTInspector ? I googled about that and just found a post of you about Bloc in the mailing list, it sounds like a good idea, and I'm sure you'll manage to do it cleanly, but I'm also very curious about that: big bang or dependency injection and small steps? other patterns, techniques ? a link on Bloc ? I'm also curious about Spec and it's status after it's change to GPL ? Will it be supported in the future ? What are the alternatives ? I understand that you are very busy, so no problem if there is no link on existing material, I should survive, just wait a little :) TIA Regards Alain Le 24/08/2014 08:03, stepharo a Ã©crit : > > On 24/8/14 05:39, Alexandre Bergel wrote: >> I see GTInspector as a big splash. I guess that if there would be a >> Tool Roadmap, it would be focused on GTInspector. > > Not necessarily. > No time to explain sorry but else I would not improve morphic because > bloc is coming and parallel actions are important. > > Stef

Aug. 25, 2014