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

Re: [Pharo-dev] [ANN] Generating beautiful html books from Pillar

by stepharo

superb Now we should continue to convert deep into pharo and updated Pharo by example to pillar :) stef On 6/6/14 18:06, Damien Cassou wrote: > Nicolas Petton and I are proud to announce the possibility to create > really nice HTML books from Pillar (I must thank > https://github.com/GitbookIO/gitbook as well). The first book to get > this nice layout is the Pillar documentation: > > http://damiencassou.gitbooks.io/pillar/introduction.pier.html > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill

June 6, 2014

[ANN] Generating beautiful html books from Pillar

by Damien Cassou

Nicolas Petton and I are proud to announce the possibility to create really nice HTML books from Pillar (I must thank https://github.com/GitbookIO/gitbook as well). The first book to get this nice layout is the Pillar documentation: http://damiencassou.gitbooks.io/pillar/introduction.pier.html -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 6, 2014

Re: [Pharo-dev] Different EOL between Save and Save As in Workspace

by stepharo

enter a bug entry. On 5/6/14 19:16, Esteban A. Maringolo wrote: > When working in a Workspace, if I choose to save using Ctrl+S, the > file will have Mac EOL (getting a lot of ^M characters when viewed > using less or vim), if I choose "Save As" it saves the file "properly" > (as expected). > > I guess this is a Bug, but maybe its not. > > Regards! > > Esteban A. Maringolo > >

June 6, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Eliot Miranda

Hi Sven, On Thu, Jun 5, 2014 at 1:57 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Here is my short, ordered list: > > - VM should run as a normal 64-bit citizen with the current 32-bit address > space > > (it is really annoying that we need 32-bit libraries, it hinders > deployment on modern virtual hardware like Xen, Docker, .. - and it makes > us look weird and old) > Yes, this is annoying but unfortunately it does not make economic sense. To have a 64-bit compiled Cog VM with 32-bit objects means - developing an x86-64 code generator that moves 32-bit units instead of the more natural 64-bit units - developing a 64-bit FFI that uses the x86-64 ABIs and converts back and forth between 32-bit objects Both of these are expensive to develop (especially the former), but give us nothing beyond what installing 32-bit libraries gives us. > - VM should break the 32-bit memory limitation and use a 64-bit address > space > Now this does make sense. In fact it is a key goal of the Spur work. That will produce a full 64-bit image complete with 61-bit SmallIntegers, and 61-bit immediate floats, and a full 64-bit FFI. This should be in production some time next year, probably second half. > (we are currently limited to 1GB of memory in use, > http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a… > - today's hardware easily offers many times more for little money, which we > should be able to use for monolithic memory persistent data structures) > In fact, we are able to allocate 1.9Gb reliably on Mac OS and 2.2Gb on linux at Cadence. But yes, the current ~ 2Gb limit is, um, limiting. The 64-bit Spur system will not suffer from this limitation. The 32-bit system may be able to grow above 2Bg on MacOS X, because Spur uses memory segments. But I haven't done any work to to ensure this works. > - Modularity in the core development > > (we have to keep Pharo lean and mean, we cannot make another mess like > the one we are still cleaning up) > > - Capitalize on our tool set by improving it > > (the magic of Pharo is, for a large part, situated in the IDE, but we > have to invest in that area to remain relevant) > > Of course, handle format X, talk protocol Y, connect to database Z are all > important, but can contributed externally. But to remain successful, we > need a solid, modern base. > +1 (in fact I'm in emphatic agreement about this one; it is my core direction to provide a great Smalltalk platform via Cog). Hence some other things that need to happen are: - refactor the VM into a small main program, a core execution engine dll/shared object, and a gui library/shared object to allow embedding Pharo/Squeak in other programs, and smaller footprint when running headless (AFAIA this is not being worked on) - provide web browser plugin capability, probably via a rendering and event channelling slave written in JavaScript that is connected to the Cog VM via sockets. (AFAIA this is not being worked on) - make NativeBoost cross platform, and implement the rules for the ARM and x86-64 ABIs in this system (this is being worked on by) - implement adaptive optimization ("sista") to provide another significant performance boost (this is being worked on). Again ClÃ©ment and I think Sista could be in production in 2015. And related to this I hope to make alpha 32-bit Spur Squeak VMs and images available today. Sven > > On 05 Jun 2014, at 10:14, phil(a)highoctane.be wrote: > > > On Thu, Jun 5, 2014 at 8:31 AM, FranÃ§ois Stephany < > tulipe.moutarde(a)gmail.com> wrote: > > As Kilon say, this is a personal wishlist. Any direction you mentioned > is worth and will have impact. > > > > However, here's my personal top 5: > > > > - **Git in the image**, that would be awesome to be able integrate the > gitflow way of developing in team. Easy branching/merging is a must. > > - **Slots**. I still need to check the current implementation and see > what's possible (Property slots?) but as I have understood you've planned > even more for pharo4? > > - **Text Editor with sensible keybindings**. > > - **ARM support** > > - **Athens** > > > > Keybindings that do work on Linux > > VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15 > > Debugger that actually doesn't throws you in space after a couple of > restart/through/over (this one really is taking power away from the whole > experience) > > Faster UI in general > > Easier Git merges without metadata issues etc > > Ability to recover frozen images (as in "Oz") > > Ability to somehow get back control of the image through some mechanism > at the VM level when frozen and no way to interrupt anything. I am ready to > pay some performance in order to work that way. > > Removal of all passwords, including whatever could be in the .changes > (which will disappear per se but you get my drift). > > +1 for Mpeg and Camera plugins; > > Traits should indeed be given a better treatment in Nautilus. > > > > Phil > > > > > > > > On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval(a)gmail.com> > wrote: > > Hi all, > > > > From my point of view, I like the progrss on the ARM VM. > > I hope to have an Android VM that works. > > Also I hope to see Pharo3.0 and Pharo4.0 working on iOS. > > > > Another question is about two interesting plugins: Mpeg3Plugin and > CameraPlugin. > > Is it possible to integrate them in the VM build ? > > > > Thank you guys for all the work done. > > Jannik > > > > > > 2014-06-04 20:53 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > > > > Hi Esteban, > > > > As you mentioned a lot of new tools and protocols were introduced, > > people (me included) does not well about those ones. > > As an example I am slowly discovering announcement and now AFAIK the > > image use three different protocols for this: change/update, observer > > and Announcement! > > Yes we know that the situation is not ideal. > > We started to move more to announcement. The problem is that some of the > widgets > > requires the change/update. For the observer I do not know what you mean. > > > > > > Personally I beg for a great Pharo 4.x series of iterative > > cleaning+consolidations. > > > > Thanks > > > > Hilaire > > > > Le 04/06/2014 17:36, Esteban Lorenzano a Ã©crit : > > Hi, > > > > A couple of weeks ago we started to plan Pharo4. This work became > stagnated for many reasons, but mainly because I needed to travel to > Argentina. > > Now I'm slowly resuming the work and I wanted to share with you what we > have been talking/dreaming. > > In esence, we have two important drivers for this release: > > > > 1) Improving tools > > Turns out that we have introduced a lot of kernel improvements (opal > compiler, layouts, slots, etc.) and tools are still not aware of them. Even > worst: we have traits since a lot of time and our tools are still now aware > enough to provide good interoperability. > > But not just that: we have introduced things that are not well used yet: > keybindings (who do not want a better keybindings structure... coherent and > editable?), spec should allow us to continue enhancing existing tools and > to replace old ones. > > > > 2) Modularisation > > One of the fundamental ideas behind Pharo is to provide a modular > environment. But well... since Pharo start to the moment, we prepared > things to allow it, but still few direct effort has been made. > > In our dreams, Pharo should be built starting for a small kernel image > and adding different modules to get a complete version. In this idea > Pharo=Kernel+GUI(Morphic)+Tools. > > This has huge advantages (I do not think is necesary to explain them, > isn't ;)?) > > > > We brainstomed around this and we get this list of issues (not all of > them directly related to the objectives, but well... good stuff also :) ) > > > > Web site: > > - add catalog > > - add videos > > - enhance it in general > > > > Infrastructure: > > - support more vm platforms > > > > VM: > > - spur > > - 64bits > > - make vm embedable and UI independent (with SDL2 and OSWindow) > > > > Image: > > - Modularisation > > - Removing old compiler > > - Repackage Morphic (to allow better modularisation) > > - Athens (replace old bitblt) > > > > Tools > > - Replace changes with Ombu/Epicea > > - Replace sources with a better abstraction > > - Git support inside image (with libgit2 + tools) > > - Pass on Spec > > - Include Glamour? > > - Make Ring unloadable > > - Fonts with FreeType > > > > And lots of bugfixes :) > > > > We would like to exchange ideas with you. > > So, what do you think? > > > > Esteban > > > > > > > > > > > > > > > > > > -- > > ~~Jannik Laval~~ > > Ãcole des Mines de Douai > > Enseignant-chercheur > > http://www.jannik-laval.eu > > http://www.phratch.com > > http://car.mines-douai.fr/ > > > > > > > > > -- best, Eliot

June 6, 2014

Re: [Pharo-dev] Rubric is too slow...

by Tudor Girba

Can you be more specific? When is it slow? Doru -- www.tudorgirba.com "Every thing has its own flow." > On 06.06.2014, at 15:45, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Sorry, it may be due to the use go GTInspector. > > Alexandre > > >> On Jun 6, 2014, at 2:50 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Hi! >> >> Since we have rubric, typing is dead slowâ¦ >> I have not done much profiling. But the method Text>>addAttribute: att from: start to: stop seems to be the culprit... >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 6, 2014

[Remainder] Call for participation to the Second Visualization Contest with Roassal

by Alexandre Bergel

Dear colleagues and friends, We are happy to announce the Second Visualization Contest with Roassal. What can I win? - 150 euros, sponsored by ObjectProfile - a Ã¼ber-cool ObjectProfile T-shirt and some wonderful stickers - maximum publicity of your work - a nice award certificate, delivered during ESUG How can I win? - you have to produce a visualization with Roassal. You can use the Pharo, VisualWorks, Amber or VAST version of Roassal. Here is an example of what we expect http://bit.ly/sunburstDemo http://bit.ly/GraphET https://vimeo.com/96091089 about smartbrowser https://vimeo.com/94724841 about GraphBuilder http://www.youtube.com/watch?v=uOmox7NgRAg&feature=youtu.be on AspectMaps, by Johan Fabry, the winner of the contest last year - making a video is mandatory. The video will weight the most in our decision. The video could be of any length and has to include your name and say that is was made (partly or completely) with Roassal. No need to talk, just show off! - making your code available and easy to install will help you get more points How can I submit? - send the links of your video and other material (if needed) to info(a)objectprofile.com Every email you will send to this email will be acknowledged. If you do not receive a 'Ok' from us, it means we haven't read it, in that case send your email again after a few days. - the deadline for submitting is August 11, 2014 Mini FAQ? - Is the object-profile team allowed to participate? No - I know nothing about Roassal, how can I start? Roassal comes with a large set of examples. On Pharo, just use the example browser available from the world menu. The book http://www.deepintopharo.com also contains chapter on Roassal 1 and Mondrian. You are also very welcome to ask question to the Pharo or Moose mailing lists about Roassal. Or simply send email to info(a)objectprofile.com . We will help you. - Iâve heard about Roassal2, Roassal3d, Roassal1. I feel lost in all these keywords! Wellâ¦ Roassal1 is available on VisualWorks and VAST. Roassal2 works on Pharo and Amber. Roassal2 is a major revamp of Roassal1. The documentation on Roassal1 may be easily adapted to Roassal2. - Should my visualization or code be open source? No need for this, whatever license is fine. However your video has to be public. - How can I get more information? Just comment on the facebook https://www.facebook.com/ObjectProfile or using Twitter @ObjectProfile or send email to info(a)objectprofile.com or the pharo or moose mailing list - What I submit two different videos? Yes, no problem with that. As many as you are productive. - Who won last year? Johan Fabry with AspectMaps made a nice video about visualizing aspects. - How will judge the videos? both the esug community and the object profile team. The Esug community will have 30% of the final grade, object profile the remaining 70% Cheers, The profilers

June 6, 2014

Re: [Pharo-dev] Rubric is too slow...

by Alexandre Bergel

Sorry, it may be due to the use go GTInspector. Alexandre On Jun 6, 2014, at 2:50 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Since we have rubric, typing is dead slowâ¦ > I have not done much profiling. But the method Text>>addAttribute: att from: start to: stop seems to be the culprit... > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 6, 2014

Rubric is too slow...

by Alexandre Bergel

Hi! Since we have rubric, typing is dead slowâ¦ I have not done much profiling. But the method Text>>addAttribute: att from: start to: stop seems to be the culprit... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 6, 2014

Re: [Pharo-dev] installing raspberry pi

by jannik laval

Hi Doru, There is a VM built by JB Arnaud: https://ci.inria.fr/pharo-contribution/view/ARM/ phratch for RPi is based on it. Cheers, Jannik 2014-06-06 12:48 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I am at NDC Oslo, and a couple of guys want to play with it on a Raspberry > Pi robot. Imagine that :). > > We tried this: > http://pharoweekly.wordpress.com/2014/02/19/raspberrypi/ > > but, it seems that the link to the vm is no longer working. > > Can anyone point me to better instructions? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

June 6, 2014

Re: [Pharo-dev] ZnClient send big data + progress

by roberto.minelli＠usi.ch

Hi Sven, Thanks a lot for the answer, itâs two days I am struggling on it! Let me know if you discover how to fix the ZdcSocketStream to behave in a good way ;) Cheers, R On Jun 6, 2014, at 1:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Roberto, > > Let's see. First we start an HTTP server in Pharo 3: > > (ZnServer defaultOn: 1701) > onRequestRespond: [ :request | > request inspect. > ZnResponse ok: (ZnEntity text: 'OK') ]; > maximumEntitySize: 100*1024*1024; > logToTranscript ; > start. > > The handler code will always reply 'OK', but also inspect the incoming request. I raise the maximum entity size to 100Mb. > > Here is a simple request: > > ZnClient new > url: 'http://localhost:1701'; > entity: (ZnEntity with: (0 to: 255) asByteArray); > post. > > Next is a bigger one (10Mb): > > ZnClient new > url: 'http://localhost:1701'; > entity: (ZnEntity with: (ByteArray new: 10*1024*1023 withAll: 123)); > post. > > Finally the big one (50Mb): > > ZnClient new > url: 'http://localhost:1701'; > timeout: 900; > entity: (ZnEntity with: (ByteArray new: 50*1024*1023 withAll: 123)); > post. > > That fails indeed, and I don't know why (yet). The weird thing is, it fails with only 6Mb written, always at the same position, while the 10Mb upload did work OK. Raising the timeout does indeed not make a difference. Data is written using 16Kb chunks, with progress notifications (see ZnUtils class>>#nextPutAll:on:). > > Luckily, there is a workaround, using the classic SocketStream somehow fixes the issue: > > ZnNetworkingUtils default socketStreamClass: SocketStream. > > Now, for the progress indication, Zinc certainly does it correctly, but somehow the UI does not always follow. You can verify this by writing to the Transcript: > > [ :bar | > bar title: 'Uploading...'. > [ > ZnClient new > signalProgress: true; > url: 'http://localhost:1701'; > entity: (ZnEntity with: (ByteArray new: 10*1024*1023 withAll: 123)); > post ] > on: HTTPProgress > do: [ :progress | > progress isEmpty ifFalse: [ bar current: progress percentage ]. > Transcript crShow: progress. > progress resume ] ] asJob run. > > Experiment with adding/commenting out the #crShow: you will see that it works, sometimes. > > HTH, > > Sven > > On 06 Jun 2014, at 10:47, roberto.minelli(a)usi.ch wrote: > >> Hi guys, >> >> I have a problem with Zinc, I need to send a huge amount of data (bytes) that translates to ~50Mb. >> >> When I do something like: >> >> ZnEasy >> post: 'http://localhost:15432' >> data: (ZnEntity bytes: aHugeByteArray.] >> >> I encounter a âConnectionTimedOut: Data send timed out.â, I attach the stack trace: >> >> ZdcSocketStream(ZdcSimpleSocketStream)>>flushBytes:startingAt:count: >> ZdcSocketStream>>next:putAll:startingAt: >> ZnBivalentWriteStream>>next:putAll:startingAt: >> ZnUtils class>>nextPutAll:on: >> ZnByteArrayEntity>>writeOn: >> ZnEntityWriter>>writeEntity: >> ZnRequest(ZnMessage)>>writeOn: >> ZnRequest>>writeOn: >> ZnClient>>executeRequestResponse >> ZnClient>>getConnectionAndExecute in Block: [ self executeRequestResponse ] >> BlockClosure>>ensure: >> ZnClient>>getConnectionAndExecute >> ZnClient>>executeWithRedirectsRemaining: >> ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... >> BlockClosure>>on:do: >> ZnClient>>executeWithRetriesRemaining: >> ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... >> BlockClosure>>on:do: >> ZnClient>>executeWithTimeout in Block: [ ... >> ZnClient>>withTimeoutDo: in Block: [ ^ block value ] >> ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ ... >> BlockClosure>>ensure: >> ZnConnectionTimeout(DynamicVariable)>>value:during: >> ZnConnectionTimeout class(DynamicVariable class)>>value:during: >> ZnClient>>withTimeoutDo: >> ZnClient>>executeWithTimeout >> ZnClient>>execute in Block: [ result := self executeWithTimeout ] >> ZnClient>>withProgressDo: in Block: [ ^ block value ] >> ZnSignalProgress(DynamicVariable)>>value:during: in Block: [ ... >> BlockClosure>>ensure: >> >> I tried to: >> - Augment the client timeout to a huge value (10 mins) but it has no effect: The data send still goes into timeout, after 10-15 sec >> - I replaced the ZnEntity with a ZnMultiPartFormDataEntity, still no luck >> >> I am wondering what else can I do. >> >> Moreover, I discovered there is a #signalProgress: message to signal process. The following examples do not work, any hint? >> >> ################################################################################ >> Example 1, from the book @ http://zn.stfx.eu/zn/zinc-http-components-paper.html: >> >> UIManager default informUserDuring: [ :bar | >> [ ^ ZnClient new >> signalProgress: true; >> get: 'http://zn.stfx.eu/echo?delay=2' ] >> on: HTTPProgress >> do: [ :progress | bar value: progress printString. progress resume ] ] >> >> ################################################################################ >> Example 2, from ZnClientTests>>#testProgress works, but not when issuing a POST request >> [ :bar | >> bar title: 'Downloading Sources...'. >> [ >> ZnClient new >> url: 'http://files.pharo.org/sources/PharoV30.sources'; >> signalProgress: true; >> downloadTo: FileLocator temp ] >> on: HTTPProgress >> do: [ :progress | >> progress isEmpty ifFalse: [ bar current: progress percentage ]. >> progress resume ] ] asJob run. >> â¦works but only when using #downloadTo: if you do a #post:contents: or a #get: as in the example with #get: 'http://zn.stfx.eu/echo?delay=10' no process is shown. Any hint? >> >> Thanks in advance, >> Roberto >> >> > >

June 6, 2014