November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [NativeBoost] pass an array of args to external function

by Igor Stasenko

sure sure.. but guys... i really doubt that i would want to see people poking with NB who don't even have a basic understanding of malloc(ed) memory management and working with memory buffers & pointers. For such sort of people, best what i can offer is "go back when you will learn basics first". Of course, it would be cool if NB could work even for "dummies", but i am thinking , as any technology, before you start using it without shooting yourself into foot, you should do some homework first. On 7 November 2012 08:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > + 1 > > On Nov 7, 2012, at 9:43 AM, Camillo Bruni wrote: > >> Just copy paste the thing you posted in the NBBasicExamples and we're >> done. A couple of examples which show common problems will help >> certainly help people to understand. >> >> Plus we should convert the examples into tests so they are always run! >> >> On 2012-11-07, at 09:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Nov 6, 2012, at 11:06 PM, Igor Stasenko wrote: >>> >>>> On 6 November 2012 17:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> This is clearly something to add to the documentation of NativeBoost. >>>>> Igor can you do it? >>>> >>>> I already have a description of memory management API for NB in docs. >>>> And telling how manage external memory is... ahem.. not really fits into docs :) >>>> Maybe a tutor or something. >>> >>> think not technical but user! >>> Id o not give a shit if what helps me is called a doc or a tutorial. >>> I care that it helps me fixing my problem. >>> And what I see is that the example of Max is a nice example of a recurring problem >>> people face. >>> >>> Stef >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> > > -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] NB integration

by Igor Stasenko

On 2 November 2012 10:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > pharo 2.0 will be "athens ready"... that means NB ready too :) > well, i actually thought that we ship "athens-ready" VMs first.. But as long as we want to put an Athens preview into image.. that will also mean having NB loaded into image. (hearing chords of 'unnecessary bloating base image size' from afar) :) eh.. everything has its cost. > On Nov 2, 2012, at 2:00 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > > > you got my vote if it is easy enough to do ;) > > ________________________________ > From: Torsten Bergmann <astares(a)gmx.de> > To: pharo-project(a)lists.gforge.inria.fr > Sent: Friday, 2 November 2012, 12:15 > Subject: [Pharo-project] NB integration > > AFAIK there was a plan to integrate NativeBoost > into Pharo. Is it for 2.0 or 2.1? > > I would like to see it for 2.0... > > Thx > T. > > > > -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] Replace ByteArray with a smaller one

by Igor Stasenko

On 7 November 2012 11:11, Camillo Bruni <camillobruni(a)gmail.com> wrote: > if the chunks you wan to cut off are big enough you could > potentially allocate a new object there which get's gc-ed. > yes.. actually you can 'crop' the existing object by modifying its size field (so VM will know it) and then for the rest bytes, mark them as a 'free chunk', which designates a unused memory space in heap. actually, this could be a good candidate for a primitive. But imo, much better strategy is to not allocate too big arrays. :) Also, as alternative , you can create a 'ArraySlice' collection class, which is a view on existing array but with smaller number or elements. And pass it around as a valid collection. > But I have no clue how to do that without VM / NB support ;) > > > On 2012-11-07, at 14:39, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Hi guys. I have a ByteArray of size N. >> And I want now only the same ByteArray but from 1 to N-X. I am using >> #copyFrom:to: but that one answers a new copy. If the ByteArray is large, >> this takes time because it needs to allocate a large object. In my case I >> don't care and I can modify the original ByteArray itself (lets say make it >> smaller, null the remaining part and change the object header info). That >> way I would avoid an extra allocation. Is there a primitive for that? >> >> Thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] [Pharo-users] Pharo consortium agreement

by Igor Stasenko

On 6 November 2012 15:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Very good that there is progress on this front ! > > Even better news about Igor ;-) > i always asking myself, if this horse worth its bets. Thank you, Stephane & others for putting trust in me more than i do :) > Indeed: thank you INRIA for sponsoring Pharo. > > I will read the document this evening. > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > On 06 Nov 2012, at 17:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Dear Pharoers >> >> Here is the result of the work we did around the consortium for Pharo for about 2 years. We took into account all your remarks over the years >> and we think that the result is good and corresponds to what the community can support. >> This consortium is important for Pharo's future and it will help us to deliver a system to help you making business. >> Our goal is to be able to collect fundings to pay at least one full time engineer. >> >> The idea is that all the consortium members will sign the same agreement. We will not handle modifications per partners. >> Now since we are starting the process if you spot some glitches on the form let us know. We can discuss and fully stabilize one version. >> >> We suggest to read the document. >> - If you agree to sign it and send it to us (in two copies if you do it by surface mail at >> INRIA - S. Ducasse - Pharo, 40, avenue Halley, Parc Scientifique de la Haute Borne, >> BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.), so that we sign it too. >> - Don't forget to complete your legal mention on first page and your contact details on article 14 before signing. :) >> >> We will launch soon two web sites: >> - one for the Pharo user association and >> - one for the Pharo consortium. >> >> >> A side note: we will communicate about it later and separately but Inria decided to support the consortium by paying one extra year to Igor Stasenko. >> This is around 60 Keuros in addition to the year of Esteban Lorenzano and previous years of Igor. >> >> I really want to thank Inria for the constant support and the work of S. Karpf, P. Moreau and S. Perin. >> >> Stef >> >> <2012-11-06-consortium PHARO.pdf> >> >> >> >> >> ------------------------ >> Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) >> INRIA - USTL - CNRS UMR 8022 >> stephane.ducasse(a)inria.fr >> http://stephane.ducasse.free.fr >> http://rmod.lille.inria.fr/ >> **NEW ***Tel 00 33 (0)3 59 35 87 52 - Fax 33 3 59 57 78 50 >> >> 40, avenue Halley, Parc Scientifique de la Haute Borne, >> BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. >> >> >> >> >> >> >> > > -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] [Jenkins] about Pharo ci infrastructure...

by Igor Stasenko

This is really good news! I really like that INRIA pays attention to issues we having and takes into account our experience and input. This is, of course, what anyone would expect from any reasonable organization :) On 7 November 2012 17:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > We are experiencing some stability issues with https://ci.lille.inria.fr/pharo/ > > But the good news is: people here have been busy, and there will be a completely new > ci infrastructure soon. > > https://ci.inria.fr > > This is right now in Beta, so please do not yet request accounts without checking with > us first (and in general, it makes only sense to have an account if you need to do > something like changing the configuration, not for normal use like downloads or checking > the status of a build). > > This setup is for inria-wide deployment, and inria is a bit larger then RMoD... there > are over 170 teams, >4500 employees... so this installation needs to be tested well before > it can be rolled out. > > The good news is that RMoD (and thus Pharo) is part of the beta test! > > TimeLine > ------------- > > -> Beta test started 31/10 > -> We will recreate the whole setup of the old jenkins there for testing > (possibly simplified using the new command line options) > -> The installation will go in production in January > > > What will it give us? > ----------------------------- > > -> We can create whole Jenkis setups by pressing a button. > (e.g. we will create a private RMoD ci server for internal things, > we could think about splitting the VM builds into it's own Jenkins, or > a jenkins for every version of Pharo...) > -> Slaves can be created easily (uses CloudStack behind) > -> external guest users can connect to the slaves via SSH (or remote Desktop for Win) > -> much better infrastructure and support > -> *Much* more resources. Disk size for Slaves, space for keeping artefacts > > > So, the ci infrastructure of Pharo will see a very boost soon. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > -- Best regards, Igor Stasenko.

Nov. 8, 2012

Re: [Pharo-project] Git API for Pharo

by Esteban A. Maringolo

Igor Stasenko wrote >> you may try changing golferReferences to goferReferences > noooo! keep golfer! i like the name :) +1 :) -- View this message in context: http://forum.world.st/Git-API-for-Pharo-tp4654219p4654383.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 7, 2012

Re: [Pharo-project] Git API for Pharo

by Igor Stasenko

On 7 November 2012 06:23, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, Nov 7, 2012 at 10:08 AM, roberto.minelli(a)usi.ch > <roberto.minelli(a)usi.ch> wrote: >> I tried to install what you proposed in a clean Pharo 1.4 image, >> but I got a MessageNotUnderstood: ByteString>>golferReferences. > > you may try changing golferReferences to goferReferences > noooo! keep golfer! i like the name :) > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > -- Best regards, Igor Stasenko.

Nov. 7, 2012

Re: [Pharo-project] unpacking cairo.tgz fails during VM build

by Igor Stasenko

On 7 November 2012 14:26, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi guys, > > While trying to compile the NBCog vm on my MacOS machine I have found a > strange issue... I do not know if it comes from my machine configuration or > if it is more general than that... > Mainly after loading the cairo package the compilation process fails to > unpack the cairo.tgz archive... It seems that the extension of the package > changes (the downloaded package has a .tar.xz extension, which gets dropped > and replaced by .tgz) and my "tar" install can't cope with that.... > > I have fixed it temporarily as shown bellow: > > CMCairo>>unpack > "..." > > gen set: #unpackTarget toString: '${libSourcesDir}/touch.cmake'. > gen puts: > 'add_custom_command(OUTPUT "${unpackTarget}" > COMMAND tar -Jxf "${libName}.tgz" > COMMAND touch "${unpackTarget}" > COMMENT "Unpacking ${libName} ... " > ) > '. > > by > > CMCairo>>unpack > "..." > gen set: #unpackTarget toString: '${libSourcesDir}/touch.cmake'. > gen puts: > 'add_custom_command(OUTPUT "${unpackTarget}" > COMMAND cp "${libName}.tgz" "${libName}.tar.xz" > COMMAND unxz "${libName}.tar.xz" > COMMAND tar xf "${libName}.tar" > COMMAND touch "${unpackTarget}" > COMMENT "Unpacking ${libName} ... " > ) > '. > > Is this a known issue, or my "tar" install is wrong? yes it is known.. i had to install 7z support for tar. this is because MacOS is number of years behind the most recent release of tar, which supports 7z compressing by default :) And with your config, i am not sure that default MacOS installation having unxz utility installed. If yes, then , of course it makes sense to change config to what is proposed by you. And if not, then it is better to leave a note in class & methods comments to indicate that people should install more recent tar utility. > > Cheers, > Ciprian > > -- > Dr. Ciprian TEODOROV > IngÃ©nieur DÃ©veloppement CAO > > tÃ©l : 06 08 54 73 48 > mail : ciprian.teodorov(a)gmail.com > www.teodorov.ro -- Best regards, Igor Stasenko.

Nov. 7, 2012

[Pharo-project] [Jenkins] about Pharo ci infrastructure...

by Marcus Denker

Hello, We are experiencing some stability issues with https://ci.lille.inria.fr/pharo/ But the good news is: people here have been busy, and there will be a completely new ci infrastructure soon. https://ci.inria.fr This is right now in Beta, so please do not yet request accounts without checking with us first (and in general, it makes only sense to have an account if you need to do something like changing the configuration, not for normal use like downloads or checking the status of a build). This setup is for inria-wide deployment, and inria is a bit larger then RMoD... there are over 170 teams, >4500 employees... so this installation needs to be tested well before it can be rolled out. The good news is that RMoD (and thus Pharo) is part of the beta test! TimeLine ------------- -> Beta test started 31/10 -> We will recreate the whole setup of the old jenkins there for testing (possibly simplified using the new command line options) -> The installation will go in production in January What will it give us? ----------------------------- -> We can create whole Jenkis setups by pressing a button. (e.g. we will create a private RMoD ci server for internal things, we could think about splitting the VM builds into it's own Jenkins, or a jenkins for every version of Pharo...) -> Slaves can be created easily (uses CloudStack behind) -> external guest users can connect to the slaves via SSH (or remote Desktop for Win) -> much better infrastructure and support -> *Much* more resources. Disk size for Slaves, space for keeping artefacts So, the ci infrastructure of Pharo will see a very boost soon. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 7, 2012

[Pharo-project] [update 2.0] #20384

by Marcus Denker

20384 ----- Issue 6931: Command Line: load image update http://code.google.com/p/pharo/issues/detail?id=6931 Issue 6932: Repository not added to some packages http://code.google.com/p/pharo/issues/detail?id=6932 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.56.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 7, 2012