- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [how about] Exceptions as first class objects *in Debugger*

by Andrei Chis

+1 I had a prototype working at a certain point that send the exception to the debugger. I'll see if I can dig it up. It just involved chancing the API methods that open the debugger. Maybe a bit late for Pharo 6. On Sun, Nov 6, 2016 at 11:04 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > +1, with that information you could describe or show the cause of the > exception > > On Sun, Nov 6, 2016 at 6:46 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Indeed this has bothered me a lot as well. >> >> At least an 'Inspect Exception' would be useful. >> >> It would also encourage people to put more useful information inside >> exception objects. >> >> > On 6 Nov 2016, at 10:38, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> > Hi, >> > >> > we have this supercool exception handling mechanism, but as soon as we >> open a debugger the exception object is goneâ¦ I understand that we didnât >> need this in old times, but now with a moldable debugger, we could create >> hooks to allow exceptions to define how they should be addressed (and >> objects are really powerful). >> > >> > Cheers. >> > Uko >> >> >> > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. >

Nov. 7, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Esteban Lorenzano

> On 7 Nov 2016, at 14:53, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > Well, maybe we can do it for Pharo 7. unless of course we find that doing it like this is incredibly easy and also we can do an âautomigration toolâ style the autodeprecation tool ;) Esteban > > 2016-11-07 14:46 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > >> On 7 Nov 2016, at 14:39, Nicolas Passerini <npasserini(a)gmail.com <mailto:npasserini@gmail.com>> wrote: >> >> >> 2016-11-07 10:37 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> NativeStructure >> subclass : #SDL_Point >> layout : StructureLayout >> slots: { #x &=> #int. #y &=> #int} >> ... >> (I got example of Ronie definition from his paper https://hal.inria.fr/hal-01353884/document <https://hal.inria.fr/hal-01353884/document>). >> So all offsets logic will go to one place StructureLayout and slots. And also we will not forced to use accessors anymore. >> >> I like this idea. >> But one question, would it be backwards compatible? (I mean, if I have current FFI invocations that use a structure in the traditional way, will I have to change all these functions if I try to migrate to this new idea?) > > no, and thatâs why I didnât considered it for now. > this is an api change, non backwards compatible and then it breaks my own criteria about Pharo6 development: no more API changes. > > but yes, in general, I like the ideaâ¦ just we cannot break things just like that (I know, I break thingsâ¦ but this is not willingly :P) > > Esteban > >

Nov. 7, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Nicolas Passerini

Well, maybe we can do it for Pharo 7. 2016-11-07 14:46 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 7 Nov 2016, at 14:39, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > > 2016-11-07 10:37 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> NativeStructure >> subclass : #SDL_Point >> layout : StructureLayout >> slots: { #x &=> #int. #y &=> #int} >> ... >> (I got example of Ronie definition from his paper >> https://hal.inria.fr/hal-01353884/document) >> So all offsets logic will go to one place StructureLayout and slots. And >> also we will not forced to use accessors anymore. >> > > I like this idea. > But one question, would it be backwards compatible? (I mean, if I have > current FFI invocations that use a structure in the traditional way, will I > have to change all these functions if I try to migrate to this new idea?) > > > no, and thatâs why I didnât considered it for now. > this is an api change, non backwards compatible and then it breaks my own > criteria about Pharo6 development: no more API changes. > > but yes, in general, I like the ideaâ¦ just we cannot break things just > like that (I know, I break thingsâ¦ but this is not willingly :P) > > Esteban > >

Nov. 7, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Esteban Lorenzano

> On 7 Nov 2016, at 14:39, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > > 2016-11-07 10:37 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > NativeStructure > subclass : #SDL_Point > layout : StructureLayout > slots: { #x &=> #int. #y &=> #int} > ... > (I got example of Ronie definition from his paper https://hal.inria.fr/hal-01353884/document <https://hal.inria.fr/hal-01353884/document>). > So all offsets logic will go to one place StructureLayout and slots. And also we will not forced to use accessors anymore. > > I like this idea. > But one question, would it be backwards compatible? (I mean, if I have current FFI invocations that use a structure in the traditional way, will I have to change all these functions if I try to migrate to this new idea?) no, and thatâs why I didnât considered it for now. this is an api change, non backwards compatible and then it breaks my own criteria about Pharo6 development: no more API changes. but yes, in general, I like the ideaâ¦ just we cannot break things just like that (I know, I break thingsâ¦ but this is not willingly :P) Esteban

Nov. 7, 2016

Re: [Pharo-dev] Belgian Pharoers and coding day proposal

by Sven Van Caekenberghe

If I can (calendar wise), I would be happy to join ! > On 7 Nov 2016, at 14:37, phil(a)highoctane.be wrote: > > I would like to propose a coding day about Pharo. > > Here is the concept: people come over to my place(max 8) we do Pharo coding and have some nice food and drinks in the process. > > I wrote Belgian pharoers but that is not a limitation, just that it would be easier if you are near the place (Wavre). > > I can also organize this at startup coworking spaces as well. > > Takers? > > Phil > > > >

Nov. 7, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Nicolas Passerini

2016-11-07 10:37 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > NativeStructure > subclass : #SDL_Point > layout : StructureLayout > slots: { #x &=> #int. #y &=> #int} > ... > (I got example of Ronie definition from his paper https://hal.inria.fr/ > hal-01353884/document). > So all offsets logic will go to one place StructureLayout and slots. And > also we will not forced to use accessors anymore. > I like this idea. But one question, would it be backwards compatible? (I mean, if I have current FFI invocations that use a structure in the traditional way, will I have to change all these functions if I try to migrate to this new idea?)

Nov. 7, 2016

Belgian Pharoers and coding day proposal

by phil＠highoctane.be

I would like to propose a coding day about Pharo. Here is the concept: people come over to my place(max 8) we do Pharo coding and have some nice food and drinks in the process. I wrote Belgian pharoers but that is not a limitation, just that it would be easier if you are near the place (Wavre). I can also organize this at startup coworking spaces as well. Takers? Phil

Nov. 7, 2016

Re: [Pharo-dev] Accessing Virtual machine internal?

by ClÃ©ment Bera

Yes. Evaluate "Smalltalk vm parameterAt: 46" it should get you the machine code zone size. You can look into the comment in the VirtualMachine class or in VirtualMachine>>getParameters method comment to see what VM internal is available. On Nov 7, 2016 19:37, "Alexandre Bergel" <alexandre.bergel(a)me.com> wrote: > Hi! > > Is there a way to get access to the VM internals? For example the size of > the method cache and the number of JIT-compiled methods? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Nov. 7, 2016

Re: [Pharo-dev] Accessing Virtual machine internal?

by Nicolai Hess

2016-11-07 13:37 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Is there a way to get access to the VM internals? For example the size of > the method cache and the number of JIT-compiled methods? > I don't know about the method cache siize, but for the number of JIT-Compiled methods is a primitive (a VMParameter) > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Nov. 7, 2016

Accessing Virtual machine internal?

by Alexandre Bergel

Hi! Is there a way to get access to the VM internals? For example the size of the method cache and the number of JIT-compiled methods? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 7, 2016