- Pharo-dev - lists.pharo.org

Fwd: [ci-announces] [Important] About Jenkins 2.x support

by Christophe Demarey

An announce from Inria CI service: > DÃ©but du message rÃ©expÃ©diÃ© : > > De: Bruno Carrez <bruno.carrez(a)inria.fr> > Objet: [ci-announces] [Important] About Jenkins 2.x support > Date: 15 novembre 2016 11:21:31 UTC+1 > Ã: ci-announces(a)inria.fr > RÃ©pondre Ã : Bruno Carrez <bruno.carrez(a)inria.fr> > > Dear CI users, > > Jenkins 2.x is around the corner for some time now; however it is not yet well supported by the Inria Continuous Integration service. > > It is STONGLY RECOMMENDED NOT TO UPDATE your Jenkins instances to 2.x versions for now. It is likely to screw your Jenkins configuration. > As for for new ci projects, Jenkins 2.x instance creation is not yet well supported! > > However, the Inria CI team is working on it and a beta support for Jenkins 2.x may arrive soon. Please, be patient. > > Best regards, > > The CI team.

Nov. 15, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Eliot Miranda

Hi Phil, On Thu, Nov 10, 2016 at 2:19 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > > On Thu, Nov 10, 2016 at 10:31 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2016-11-10 9:49 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >>> Ah, but then it may be more interesting to have a data image (maybe a >>> lot of these) and a front end image. >>> >>> Isn't Seamless something that could help us here? No need to bring the >>> data back, just manipulate it through proxies. >>> >> >> Problem that server image will anyway perform GC. And it will be slow if >> server image is big which will stop all world. >> > > What if we asked it to not do any GC at all? Like if we have tons of RAM, > why bother? Especially if what it is used to is to keep datasets: load > them, save image to disk. When needed trash the loaded stuff and reload > from zero. > > Basically that is what happens with Spark. > > http://sujee.net/2015/01/22/understanding-spark-caching/#.WCRIgy0rKpo > https://0x0fff.com/spark-misconceptions/ > While global GC may not be useful for big-data scavenging probably will be for any non-trivial query. But I think I see a misconception here. The large RAM on a multiword machine would be divided up between the cores. It makes no sense to run a single Smalltalk across lots of cores (we're a long way from having a thread-safe class library). It makes much more sense to have one Smalltalk per core. So that brings the heap sizes down and makes GC less scary. > and Tachyon/Alluxio is kind of solving this kind of issue (may be nice to > have that interacting with Pharo image). http://www.alluxio.org/ This > thing basically keeps stuff in memory in case one needs to reuse the data > between workload runs. > Sure. We have all the facilities we need to do this. We can add and remove code at runtime so we can keep live instances running, and send the code to them along with the data we want them to crunch. > > Or have an object memory for work and one for datasets (first one gets > GC'd, the other one isn't). > Or have policies which one can switch. There are quite a few levers into the GC from the image and one can easily switch off global GC with the right levers. One doesn't need a VM that doesn't contain a GC. One needs an image that is using the right policy. Phil > _,,,^..^,,,_ best, Eliot

Nov. 15, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Eliot Miranda

On Thu, Nov 10, 2016 at 1:31 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-11-10 9:49 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> Ah, but then it may be more interesting to have a data image (maybe a lot >> of these) and a front end image. >> >> Isn't Seamless something that could help us here? No need to bring the >> data back, just manipulate it through proxies. >> > > Problem that server image will anyway perform GC. And it will be slow if > server image is big which will stop all world. > Which is why we plan on implementing an incremental global GC that will not stop the world, but will divide global GC up into many small steps, each of which will be shorter than 10 milliseconds, and so not be noticeable. _,,,^..^,,,_ best, Eliot

Nov. 15, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by Thierry Goubier

Le 14/11/2016 Ã 21:51, stepharo a Ã©crit : > Hi thierry > > > did you happen to have a techreport or any description of your work? It's a chapter in my PhD thesis ;) Thierry > > Stef > > > Le 11/11/16 Ã 11:44, Thierry Goubier a Ã©crit : >> Le 11/11/2016 Ã 11:29, Stephan Eggermont a Ã©crit : >>> On 10/11/16 21:35, Igor Stasenko wrote: >>>> No, no, no! This is simply not true. >>>> It is you, who writes the code that generates a lot of statistical >>>> data/analysis data, and its output is fairly predictable.. else you are >>>> not collecting any data, but just a random noise, isn't? >>> >>> That would be green field development. In brown field development, I >>> only get in when people start noticing there is a problem (why do we >>> need more than 4GBytes for this?). At that point I want to be able to >>> load everything they can give me in an image so I can start analyzing >>> and structuring it. >>> >>>> I mean, Doru is light years ahead of me and many others in field of >>>> data >>>> analysis.. so what i can advise to him on his playground? >>> >>> Well, the current FAMIX model implementation is clearly not well >>> structured for analyzing large code bases. And it is difficult to >>> partition because of unpredictable access patterns and high >>> interconnection. >> >> This is why you look for a general purpose, efficient off-loading >> scheme, trying to optimize a general case and get reasonable >> performance out of it (a.k.a fuel, but designed for partial unloading >> / loading: allow dangling references in a unit of load, focus on >> per-page units to match the underlying storage layer or network). >> >> I wrote one such layer for VW a long time ago, but didn't had time to >> experiment / qualify some of the techniques in it. There was an >> interesting attempt (IMHO ... wasn't qualified) at combining paging >> and automatic refinement of application working set, based on previous >> experience implementing a hierarchical 2D object access scheme for >> large datasets on slow medium (decreased access time from 30 minutes >> to about a few seconds). >> >> The other approach I would look is take some of the support code for >> such an automatic layer and use it to unload parts of my model;, and >> I'm pretty sure that, if I don't bench intensively, I'll get the >> partitioning wrong :( >> >> Overall, an interesting subject, totally not valid from a scientific >> point of view (the database guys have already solved everything). Only >> valid as a hobby, or if a company is ready to pay for a solution. >> >> Thierry >> >> > > >

Nov. 14, 2016

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

by stepharo

Hi thierry did you happen to have a techreport or any description of your work? Stef Le 11/11/16 Ã 11:44, Thierry Goubier a Ã©crit : > Le 11/11/2016 Ã 11:29, Stephan Eggermont a Ã©crit : >> On 10/11/16 21:35, Igor Stasenko wrote: >>> No, no, no! This is simply not true. >>> It is you, who writes the code that generates a lot of statistical >>> data/analysis data, and its output is fairly predictable.. else you are >>> not collecting any data, but just a random noise, isn't? >> >> That would be green field development. In brown field development, I >> only get in when people start noticing there is a problem (why do we >> need more than 4GBytes for this?). At that point I want to be able to >> load everything they can give me in an image so I can start analyzing >> and structuring it. >> >>> I mean, Doru is light years ahead of me and many others in field of >>> data >>> analysis.. so what i can advise to him on his playground? >> >> Well, the current FAMIX model implementation is clearly not well >> structured for analyzing large code bases. And it is difficult to >> partition because of unpredictable access patterns and high >> interconnection. > > This is why you look for a general purpose, efficient off-loading > scheme, trying to optimize a general case and get reasonable > performance out of it (a.k.a fuel, but designed for partial unloading > / loading: allow dangling references in a unit of load, focus on > per-page units to match the underlying storage layer or network). > > I wrote one such layer for VW a long time ago, but didn't had time to > experiment / qualify some of the techniques in it. There was an > interesting attempt (IMHO ... wasn't qualified) at combining paging > and automatic refinement of application working set, based on previous > experience implementing a hierarchical 2D object access scheme for > large datasets on slow medium (decreased access time from 30 minutes > to about a few seconds). > > The other approach I would look is take some of the support code for > such an automatic layer and use it to unload parts of my model;, and > I'm pretty sure that, if I don't bench intensively, I'll get the > partitioning wrong :( > > Overall, an interesting subject, totally not valid from a scientific > point of view (the database guys have already solved everything). Only > valid as a hobby, or if a company is ready to pay for a solution. > > Thierry > >

Nov. 14, 2016

Re: [Pharo-dev] macOS Sierra support

by stepharo

Good Tx Le 14/11/16 Ã 11:36, Esteban Lorenzano a Ã©crit : > for the moment, I added this nice (?) alert when you press mac > download button: > > >> On 14 Nov 2016, at 11:30, Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>> wrote: >> >> >>> On 14 Nov 2016, at 11:01, MartinW <wm(a)fastmail.fm >>> <mailto:wm@fastmail.fm>> wrote: >>> >>> Can someone put a note to the website (http://pharo.org/download)? It is >>> frustrating for users to follow the link to >>> http://files.pharo.org/platform/Pharo5.0-mac.zip from there and get a >>> defunct Pharo installation. >> >> no, in fact that link should work. >> â¦ and in fact, it worksâ¦ is just that due the changes in sierra, the >> bundle needs to be put in /Applications to not be copied into a >> sandbox, readonly place. >> >> Iâm working on have this working in a different way: is time to make >> PharoLauncher the default download. That way it will be in >> /Applications naturally and your images will be in a correct place >> naturally (I also would like a âadd command line toolsâ option to >> install a pharo and pharo-ui in /usr/local/bin). >> >> Esteban >> >>> >>> >>> Sean P. DeNigris wrote >>>> >>>> EstebanLM wrote >>>>> the regular download by zeroconf should give you an usable VM. >>>> That worked - thanks! >>> >>> Yes, this VM works well :) >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/macOS-Sierra-support-tp4917181p4922891.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com <http://Nabble.com>. >>> >> >

Nov. 14, 2016

[ANN] WKHTML2PDF converted to UFFI

by Torsten Bergmann

Hi, WKHTML2PDF was broken in recent Pharo version as my original version of the project was based on NativeBoost and we now meanwhile switched to UFFI with Pharo to provide a unified foreign function interface. Long story short: I now found the time to update the project to use UFFI and make it work again. You can load it from Catalog in Pharo 5/6. So if you like to convert HTML or URLs to a PDF use HTML2PDFConverter convert: 'http://www.pharo.org' toFile: 'pharo.pdf' then check it out. Note that I only had the need to make it work on Windows. If someone adopts to Linux/Mac tell me and we include the contribution. Project is on STHub as before: http://smalltalkhub.com/#!/~TorstenBergmann/WKHTML2PDF Thanks T.

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Torsten Bergmann

I was hit by this today already as it made Catalog slow like hell (which I fixed): https://pharo.fogbugz.com/f/cases/19342/. +1 for the short-term revert +10 for aligning Squeak and Pharo with a more intention revealing name Thx T. > Gesendet: Montag, 14. November 2016 um 19:49 Uhr > Von: "Eliot Miranda" <eliot.miranda(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Cc: squeak-dev(a)lists.squeakfoundation.org > Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector > > Hi All, > > can I suggest that Pharo and Squeak coordinate on a change. First, #selector is bad because it is ambiguous. As already determined #keyword is awful because it's false (it is a message selector, not just a keyword). So could we > > - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword? > > - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)? > > _,,,^..^,,,_ (phone) > > > On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > > 2016-11-14 11:27 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> Breaking Metacello in Pharo 6: Not good. Revert: +1 > > > > Breaking Metacello in any version = Not good. > > > > Metacello is very backward compatible but breaking pragma semantics > > would require a rewrite of many configurations that work okay today > > and would require a new version of Metacello that contemplates the new > > selectors based on some criteria. > > > > Regards! > > > > Esteban A. Maringolo > > > >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by phil＠highoctane.be

Here is the CI thing for Travis. https://github.com/hpi-swa/smalltalkCI Phil On Mon, Nov 14, 2016 at 7:15 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 14/11/2016 Ã 18:12, Denis Kudriashov a Ã©crit : > > > > But we already has fork of Metacello in image. Many Metacello packages > > are from integrator. > > So loading latest version is not possible now. And merge will not be > > easy task anyway. > > But maybe I am wrong here. > > For some projects as MaterialDesignLite I need the latest version of > Metacello so I load it. Before the change in pragma it was fine. > > Dale try to keep Metacello running on Pharo with TravisCI I think. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Nov. 14, 2016

Re: [Pharo-dev] Pragma keyword / selector / methodSelector

by Eliot Miranda

Hi All, can I suggest that Pharo and Squeak coordinate on a change. First, #selector is bad because it is ambiguous. As already determined #keyword is awful because it's false (it is a message selector, not just a keyword). So could we - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword? - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)? _,,,^..^,,,_ (phone) > On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2016-11-14 11:27 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> Breaking Metacello in Pharo 6: Not good. Revert: +1 > > Breaking Metacello in any version = Not good. > > Metacello is very backward compatible but breaking pragma semantics > would require a rewrite of many configurations that work okay today > and would require a new version of Metacello that contemplates the new > selectors based on some criteria. > > Regards! > > Esteban A. Maringolo >

Nov. 14, 2016