- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Screenshot of Pharo 64 bits

by Esteban Lorenzano

> On 25 May 2016, at 14:46, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Wed, May 25, 2016 at 11:27:04AM +0200, Cl??ment Bera wrote: >> There are quite some progress on the plugin work. >> >> Eliot made x64 FFI working a couple months ago. >> >> Nicolas Cellier have already been looking for Number plugins for a while. >> >> Many Slang compilation bugs related to 32-64 bits dependency were fixed, so >> many plugins work out of the box. > > The commonly required plugins have been working for quite a few years on > all combinations of 32/64 bit VM and image. I'm sure there will still be > some issues to address as we move to Spur 64, but I expect that most plugins > will work. yes, they do workâ¦ but we still have another set that needs to be verified (like FT2, for example) > > Dave > > >> >> Other plugins w >> >> On Wed, May 25, 2016 at 11:02 AM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> >>> And this marked the start of a new era. >>> >>> Kudos guys. >>> >>> Now, plugin time I guess... >>> >>> Phil >>> >>> On Tue, May 24, 2016 at 3:25 PM, Cl??ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> >>>> Today I helped Esteban porting the 32 to 64 bits bootstrap to Pharo. It >>>> looks like we have a Pharo 64 bits image on 64 bits VM running on Mac & >>>> Linux. >>>> >>>> Here is the wonderful screenshot showing the amazing result: >>>> >>>> [image: Inline image 1] >>>> >>> >>> > > >

May 25, 2016

Re: [Pharo-dev] Screenshot of Pharo 64 bits

by David T. Lewis

On Wed, May 25, 2016 at 11:27:04AM +0200, Cl??ment Bera wrote: > There are quite some progress on the plugin work. > > Eliot made x64 FFI working a couple months ago. > > Nicolas Cellier have already been looking for Number plugins for a while. > > Many Slang compilation bugs related to 32-64 bits dependency were fixed, so > many plugins work out of the box. The commonly required plugins have been working for quite a few years on all combinations of 32/64 bit VM and image. I'm sure there will still be some issues to address as we move to Spur 64, but I expect that most plugins will work. Dave > > Other plugins w > > On Wed, May 25, 2016 at 11:02 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > > And this marked the start of a new era. > > > > Kudos guys. > > > > Now, plugin time I guess... > > > > Phil > > > > On Tue, May 24, 2016 at 3:25 PM, Cl??ment Bera <bera.clement(a)gmail.com> > > wrote: > > > >> Today I helped Esteban porting the 32 to 64 bits bootstrap to Pharo. It > >> looks like we have a Pharo 64 bits image on 64 bits VM running on Mac & > >> Linux. > >> > >> Here is the wonderful screenshot showing the amazing result: > >> > >> [image: Inline image 1] > >> > > > >

May 25, 2016

[pharo-project/pharo-core] 971dfd: 50758

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 971dfd230d94486ff46d4def2dd3248c492d14ca https://github.com/pharo-project/pharo-core/commit/971dfd230d94486ff46d4def… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-25 (Wed, 25 May 2016) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50757.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50758.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50757.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50758.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50758 18284 SmallFloat64 identityHash is answering bad value https://pharo.fogbugz.com/f/cases/18284 http://files.pharo.org/image/50/50758.zip

May 25, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50758 Home: https://github.com/pharo-project/pharo-core

May 25, 2016

[UFFI] Call a function where argument type is char ** (argv)

by Blondeau Vincent

Hello, I have written a R bridge in Pharo and I would like to migrate it from NativeBoost to UFFI. Most of the changes are easy to do but I am stuck to a double pointer problem. I have to call the function: int Rf_initEmbeddedR(int argc, char ** argv). I know how to give the int but the char ** is a problem. With NB, I managed to have this (working) code: "This is 32bit... too bad..." strings := OrderedCollection new. par := NativeBoost allocate: 4 * params size. params keysAndValuesDo: [ :i :each | | str | str := each asNBExternalString. strings add: str. par nbUInt32AtOffset: (i - 1) * 4 put: str value ]. self prim_initEmbeddedRargc: params size argv: par ] ensure: [ "Free the memory we allocated" par ifNotNil: [ par free ]. strings ifNotNil: [ strings do: [ :each | each free ] ] ] With a primitive call: Self nbCall: #(int Rf_initEmbeddedR(int argc, char *argv)) Do I still need to create my own array of strings or FFI creates it for me? How? Thanks in advance for your answers, Vincent !!!************************************************************************************* "Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

May 25, 2016

Do we want AST-Debugger?

by Denis Kudriashov

Hi. Look at AST-Interpreter project which includes AST-Debugger http://smalltalkhub.com/#!/~Pharo/AST-Interpreter. Code is so simple comparing to "bytecode simulation" approach of current debugger. AST debugger are independent from bytecode set. It just visit AST-nodes to simulate code execution. But current debugger simulates bytecode. It depends on current bytecode set. There are few kinds of BytecodeEncoders. To understand how current debugger is working you need to know many VM details. So my question is why our debuggers are not based on AST interpreter? Why it is bad idea? (if it is bad). Best regards, Denis

May 25, 2016

Re: [Pharo-dev] Screenshot of Pharo 64 bits

by ClÃ©ment Bera

There are quite some progress on the plugin work. Eliot made x64 FFI working a couple months ago. Nicolas Cellier have already been looking for Number plugins for a while. Many Slang compilation bugs related to 32-64 bits dependency were fixed, so many plugins work out of the box. Other plugins w On Wed, May 25, 2016 at 11:02 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > And this marked the start of a new era. > > Kudos guys. > > Now, plugin time I guess... > > Phil > > On Tue, May 24, 2016 at 3:25 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> Today I helped Esteban porting the 32 to 64 bits bootstrap to Pharo. It >> looks like we have a Pharo 64 bits image on 64 bits VM running on Mac & >> Linux. >> >> Here is the wonderful screenshot showing the amazing result: >> >> [image: Inline image 1] >> > >

May 25, 2016

Re: [Pharo-dev] strange Zinc JPEG bug

by Sven Van Caekenberghe

Here is the fix: === Name: Zinc-HTTP-SvenVanCaekenberghe.450 Author: SvenVanCaekenberghe Time: 25 May 2016, 11:02:23.445172 am UUID: 2785db13-be7c-4ec1-86ce-ca8b4d58bae1 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.449 Re-implement ZnEasy class >> #get[Png|Jpeg|Gif] so that ImageReadWriter decides on the parser to use by checking the magic header, instead of hardcoding a specific subclass. This was necessary because the plugin based JPEG parser was not being used, while it should. Add ZnEasyTests>>#testGetGif and #testGetPng === Name: Zinc-Tests-SvenVanCaekenberghe.237 Author: SvenVanCaekenberghe Time: 25 May 2016, 11:02:43.330855 am UUID: 4a6b5827-daf2-4ccf-b452-cf08e84feb9b Ancestors: Zinc-Tests-SvenVanCaekenberghe.236 Re-implement ZnEasy class >> #get[Png|Jpeg|Gif] so that ImageReadWriter decides on the parser to use by checking the magic header, instead of hardcoding a specific subclass. This was necessary because the plugin based JPEG parser was not being used, while it should. Add ZnEasyTests>>#testGetGif and #testGetPng === > On 24 May 2016, at 21:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 24 May 2016, at 20:11, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> >> >> On Tue, May 24, 2016 at 7:50 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: >> Not sure where to report zinc bugsâ¦ fogzbugz? or is it a separate project? >> >> Any bug found in the standard image regardless of project should be reported on fogbugz, no? >> >> >> Ah, good point. >> >> >> >> >> but this works just fineâ¦ >> >> If I do: >> >> >> >> | imageStream | >> >> >> >> imageStream := (ZnEasy get: 'http://orig13.deviantart.net/e8d3/f/2013/092/a/3/glados_s_activation_by_fir…') contents readStream. >> >> >> >> JPEGReadWriter formFromStream: imageStream. >> >> >> >> It will give me an error âimage format not recognizedâ. >> >> >> >> ImageReadWriter chooses to use PluginBasedJPEGReadWriter instead of JPEGReadWriter (ImageReadWriter >>#readerClassFromStream: ). >> >> >> >> So perhaps #getJpeg: should use the PluginBasedJPEGReadWriter or have a fallback on error trying once more by using ( >> >> JPEGReadWriter formFromStream: theStream ) ? >> >> >> What's the difference? Why do we have two clasees for reading JPEGs? >> >> Peter > > One is implemented in pure Pharo code, the other is plugin based, C code calling a library, and is much faster (and presumable more capable in handling weird cases). > > I always assumed the fastest one was used automatically, but apparently not. > > This works: > > PluginBasedJPEGReadWriter formFromStream: (ZnEasy get: 'http://orig13.deviantart.net/e8d3/f/2013/092/a/3/glados_s_activation_by_fir…') entity readStream. > > I'll have to look into this. > > Sven >

May 25, 2016

Re: [Pharo-dev] strange Zinc JPEG bug

by Sven Van Caekenberghe

> On 25 May 2016, at 08:42, stepharo <stepharo(a)free.fr> wrote: > > > > Le 24/5/16 Ã 19:50, Henrik Nergaard a Ã©crit : >> Not sure where to report zinc bugsâ¦ fogzbugz? or is it a separate project? >> Any bug found in the standard image regardless of project should be reported on fogbugz, no? > > Yes I imgaine that there is zinc project there else we should create one. Of course there is a Zinc category. >> but this works just fineâ¦ >> If I do: >> >> | imageStream | >> >> imageStream := (ZnEasy get: 'http://orig13.deviantart.net/e8d3/f/2013/092/a/3/glados_s_activation_by_fir…') contents readStream. >> >> JPEGReadWriter formFromStream: imageStream. >> >> It will give me an error âimage format not recognizedâ. >> >> ImageReadWriter chooses to use PluginBasedJPEGReadWriter instead of JPEGReadWriter (ImageReadWriter >>#readerClassFromStream: ). >> >> So perhaps #getJpeg: should use the PluginBasedJPEGReadWriter or have a fallback on error trying once more by using ( >> JPEGReadWriter formFromStream: theStream ) ? >> >> Best regards, >> Henrik >> >> >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Peter UhnÃ¡k >> Sent: Tuesday, May 24, 2016 6:37 PM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: [Pharo-dev] strange Zinc JPEG bug >> >> Hi, >> >> Offray discovered a strange Zinc bug when reading a JPEG. >> Not sure where to report zinc bugsâ¦ fogzbugz? or is it a separate project? >> >> This fails on "marker D0 cannot be handled" >> >> image := ZnEasy getJpeg: 'http://orig13.deviantart.net/e8d3/f/2013/092/a/3/glados_s_activation_by_fir…'. >> World backgroundImage: image layout: #scaled. >> >> but this works just fine >> >> image := (ImageReadWriter formFromStream: (ZnEasy get: 'http://orig13.deviantart.net/e8d3/f/2013/092/a/3/glados_s_activation_by_fir…') contents readStream). >> World >> backgroundImage: image >> layout: #scaled. >> >> Peter > >

May 25, 2016

Re: [Pharo-dev] Screenshot of Pharo 64 bits

by phil＠highoctane.be

And this marked the start of a new era. Kudos guys. Now, plugin time I guess... Phil On Tue, May 24, 2016 at 3:25 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Today I helped Esteban porting the 32 to 64 bits bootstrap to Pharo. It > looks like we have a Pharo 64 bits image on 64 bits VM running on Mac & > Linux. > > Here is the wonderful screenshot showing the amazing result: > > [image: Inline image 1] >

May 25, 2016