- Pharo-dev - lists.pharo.org

[Pharo-project] [Jenkins] Failing tests 2.0

by Marcus Denker

Issue 6929: Undeclared ManifestManifestResourcesTests http://code.google.com/p/pharo/issues/detail?id=6929 Issue 6927: Failing test for Manifest http://code.google.com/p/pharo/issues/detail?id=6927 Issue 6928: Obsolete class after running all tests http://code.google.com/p/pharo/issues/detail?id=6928 Issue 6309: Failing test on Windows related to SocketStream http://code.google.com/p/pharo/issues/detail?id=6309 -- Marcus Denker -- http://marcusdenker.de

Nov. 7, 2012

Re: [Pharo-project] SqueakSource Mails

by Tobias Pape

Am 07.11.2012 um 14:03 schrieb Sven Van Caekenberghe: > Guys, > > I am receiving hundreds of old commit emails from SqueakSource since the latest restart. This happened before as well. Is anybody else seeing this as well ? And can something be done about this ? > > Sven I see them as well. As far as I know SqueakSource, the only option is to disable Commit mails for your project altogether. Best -Tobias

Nov. 7, 2012

Re: [Pharo-project] SqueakSource Mails

by Fabrizio Perin

Hi Sven, it happened to me too. not sure what the right solution is. It will eventually stop. what you can do is to unregister yourself from receiveing commit email notifications. Cheers, Fabrizio 2012/11/7 Sven Van Caekenberghe <sven(a)stfx.eu>: > Guys, > > I am receiving hundreds of old commit emails from SqueakSource since the latest restart. This happened before as well. Is anybody else seeing this as well ? And can something be done about this ? > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Nov. 7, 2012

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

by Norbert Hartl

So, what's best. Wait to finalize the form or print and send? Norbert Am 06.11.2012 um 17:24 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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. > > > > > > > > _______________________________________________ > Pharo-consortium mailing list > Pharo-consortium(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-consortium

Nov. 7, 2012

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

by Camillo Bruni

if the chunks you wan to cut off are big enough you could potentially allocate a new object there which get's gc-ed. 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

Nov. 7, 2012

Re: [Pharo-project] Cheating NB FFI ByteArray size

by Camillo Bruni

just never forget that we have a moving GC! ;) so directly passing references to native function can be quite dangerous! Otherwise you could first manually adjust the start address by writing the corresponding ASM code ;) then run the C callout. I should check if we already have a proper helper method for that. On 2012-11-07, at 14:33, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Igor. I wonder if I can do the following. > I have to pass a ByteArray to a function that expects an already malloced > char*. > So far it is working fine. Now...what I would like is from the image side > to allocate a ByteArray of size + 4. I need to reserve the first 4 bytes of > the ByteArray for something. But the library I am calling doesn't let me > specify where to start from that char*. > So...can I cheat? I mean, can I allocate ByteArray+4 in the image, but when > passing it as an argument somehow say "ok, take this ByteArray but think > the the beginning is the byte 4" ? > or something like that ? > > Thanks! > > -- > Mariano > http://marianopeck.wordpress.com

Nov. 7, 2012

[Pharo-project] Replace ByteArray with a smaller one

by Mariano Martinez Peck

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

Nov. 7, 2012

[Pharo-project] Cheating NB FFI ByteArray size

by Mariano Martinez Peck

Hi Igor. I wonder if I can do the following. I have to pass a ByteArray to a function that expects an already malloced char*. So far it is working fine. Now...what I would like is from the image side to allocate a ByteArray of size + 4. I need to reserve the first 4 bytes of the ByteArray for something. But the library I am calling doesn't let me specify where to start from that char*. So...can I cheat? I mean, can I allocate ByteArray+4 in the image, but when passing it as an argument somehow say "ok, take this ByteArray but think the the beginning is the byte 4" ? or something like that ? Thanks! -- Mariano http://marianopeck.wordpress.com

Nov. 7, 2012

[Pharo-project] SqueakSource Mails

by Sven Van Caekenberghe

Guys, I am receiving hundreds of old commit emails from SqueakSource since the latest restart. This happened before as well. Is anybody else seeing this as well ? And can something be done about this ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 7, 2012

[Pharo-project] [update 2.0] #20383

by Esteban Lorenzano

20383 ----- Issue 6921: Better handling of smart characters http://code.google.com/p/pharo/issues/detail?id=6921 Issue 6914: cleanUpForProduction is not unloading Metacello inf http://code.google.com/p/pharo/issues/detail?id=6914 Issue 6910: Nautilus enable CMD-R for renaming temporaries http://code.google.com/p/pharo/issues/detail?id=6910 Issue 3816: Time millisecondClockValue wraps around way too quickly http://code.google.com/p/pharo/issues/detail?id=3816 Diff information: http://ss3.gemstone.com/ss/Pharo20/Text-EstebanLorenzano.35.diff http://ss3.gemstone.com/ss/Pharo20/Network-Kernel-EstebanLorenzano.74.diff http://ss3.gemstone.com/ss/Pharo20/NautilusRefactoring-EstebanLorenzano.55.… http://ss3.gemstone.com/ss/Pharo20/NECompletion-EstebanLorenzano.64.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-EstebanLorenzano.1234.diff

Nov. 7, 2012