September 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Copy from Code::Blocks on Linux
by Schwab,Wilhelm K Sept. 23, 2010

Sept. 23, 2010

Hello all, A frequent problem I encounter: select and copy text from an editor in Code::Blocks; on pasting into Pharo, I get something other than what I copied. Any ideas what might be happening? Are there multiple clipboards on Linux? Could it be a mismatch in format? I'm using Ubuntu. I frequently work around this by pasting the code into gedit and then copying again from there, after which Pharo "sees" it. Bill

2 1

[Pharo-project] decompiledSource
by Herve Verjus Sept. 23, 2010

Sept. 23, 2010

Hello All, I would like to port some VisualWorks code into Pharo. The VW current project code uses VW Kernel.decompiledSource that does not seem to be implemented in Pharo...Is there a Pharo method that does the same...Is there someone with an idea ? Thank you... Herve

3 2

Re: [Pharo-project] NativeBoost examples (was: Re: DoubleArray)
by StÃ©phane Ducasse Sept. 23, 2010

Sept. 23, 2010

igor May be a layer for people that are not fluent with assembly would help. Make the path easy from FFI writing. Get some patterns so that people can learn by following patterns. Stef On Sep 23, 2010, at 3:07 PM, Igor Stasenko wrote: > On 23 September 2010 06:11, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The examples that make sense depend on what NativeBoost wants to be when it grows up. Is it a full competitor to FFI and/or Alien? If so, then it would be nice to see a rich set of calls to functions with different parameter types; ideally it would be in the form of something useful that gets added to Pharo using NativeBoost. That does a couple of things, providing both proof of concept and examples in one shot. >> > One major 'proof of concept' kinda, is NBOpenGL package, which > provides a full OpenGL bindings by using NativeBoost :) > But sure thing, basic examples is a must. That's why i asked you , > whant you wanna see. > > I have no idea, what can be userful to pharoers , since i can do > anything and its completely trivial for me to implement, > as an author of this project ;) > So, without some feedback, i have no idea, if something in my code > looks confusing, or hard to use and needs > deeper explanation(s) and examples. > >> With tongue firmly in cheek, looking at your indexing example, my stack might pop before the machine's :) However, it looks like it should settle down quickly enough, and things like that go on in the vm all the time; you are arguably just brining it into the image. > > Indeed. Arguably. You putting your code into an image, instead of extra plugin. > So, once your code is debugged and works well, you are done, and don't > have to worry with shipping a custom VM/plugin > with your product. The development and deployment of new primitives is > much faster if you using NB. > >> Where would #readDoubleFrom: be in the class hiearchy? One of the reasons I asked about indexing an external array is that FFI is not good at such things. If you can provide ways to copy, fill, etc. blocks of memory and do it quickly, you gain ground, assuming you want to compete with FFI. > > In this particular example, you can do a usual way - make a > DoubleArray class, which is a subclass > of ByteArray , then implement #at: and #at:put: using nativeboost. > Implement various stuff to fully cover Collection protocol, > implement any extra stuff like blob operations (multiplication, > addition etc) if you want. > > And you don't have to compete with FFI, since you can implement all > primitives in NativeBoost without using any external functions. > You can use any kind of optimizations in native code, which are not > available in C, like using SSE/SIMD instructions etc. > Even more, you can detect a CPU type, and depending on that, generate > a most efficient code for your little class/library. > >> >> Do callbacks, and you gain a lot of ground. Make calls on separate threads, and you gain a LOT of ground. That assumes that you can make it simple enough for a mildly above-average C programmer to understand how to use and ideally extend it. I will look at your example package on Squeak Source. > > Callbacks is there. See NBFFICallbackTests>>benchQSort for example. > >> >> One thing that drives me nuts with the Linux vm is that it looks for things where it wants to look, and gives no feedback about what it tried to do or even that it failed (except that handle is still zero). Your callout pragmas take a module name; is there any way to see inside of that or to provide a full path to the library? It is nice to be able to confirm loading of a library w/o having to call something, since there won't always be something "safe" (free of side effects) to call as a test. >> > > Wait, there is no callout pragmas.. > All stuff which starts from > > ^ NBFFICallout > cdecl: #( double ( void * address) ) ... > > is smalltalk code, and you can debug it and see what it does, and how > it loading a module and retrieving an external function > pointer from it. > You can customize this procedure in any way you want (by subclassing > NBFFICallout), you can even customize the way how you making a call. > > For instance, in NBOpenGL, a generated code does not making a direct > call to previously discovered function address. > It using an sub-instance of NBOpenGLAPIBase, which is a > variable-sized object, holding a function pointers, > and it reads a corresponding pointer from this object, and only then > making a call. > > So, there are plenty various tricks which can be done without much > hassle. You just need to step away from rigid patterns, > imposed by C compler, linker and all stuff around that, and you will > see, that you can do miracles in smalltalk + native code :) > >> At the risk of seeming difficult, everything is academic until we have a Linux plugin or at least can build same. Alien has that problem. > > I'm working on that. > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >> Sent: Wednesday, September 22, 2010 10:05 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] NativeBoost examples (was: Re: DoubleArray) >> >> On 23 September 2010 02:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>> Sig, >>> >>> Fair enough :) The most recent thing I recall on NativeBoost is Stef asking for what I assume must be a Mac plugin; I thought Linux would be left out too, but it appears not, though it is not in my current vm. Beyond some list traffic, I found this: >>> >> >> The work for supporting Linux and Mac is in progress. >> >>> http://code.google.com/p/nativeboost/wiki/NativeBoost >>> >>> Is there other documentation somewhere? Build instructions? >> >> You can find all existing documentation, installation instructions on >> wiki pages at the above site. There is no other place for it. >> http://code.google.com/p/nativeboost/wiki/Installation - installation >> instructions. >> >>> You have a block copy, which is good. What about indexing, such as getting floats or doubles out of external memory? >> >> This is just a piece of cake. ;) >> >> readDoubleFrom: address >> " This method loads the double from given external address. >> an address can be an instance of NBExternalAddress, or >> simple ByteArray with at least 8 bytes long, which holds a double >> floating value" >> >> <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> >> "We are using a pseudo-function prototype and supplying own assembler code, >> instead of making a call to external function. >> In given example, an address argument , after coercion is pushed on stack. " >> >> ^ NBFFICallout >> >> cdecl: #( double ( void * address) ) >> " A pseudo-function takes 1 argument, and returns double value. >> Under cdecl call convention, all floating point return types is >> returned in fp(0) CPU register" >> >> emitCall: [:gen | | asm | >> asm := gen asm. >> >> "Here , we expecting that an address value is already pushed on stack" >> >> asm pop: asm EAX; "load an address value into EAX register by >> popping a stack" >> fld: (asm EAX ptr64). "load a floating point value from memory, at >> base address, held in EAX register into fp(0) register, >> we are using #ptr64, to indicate that memory operand size is 64bits long" >> >> " return value set, we are done. A code generator will take care >> for emitting code, which converts >> a double floating point value into smalltalk object. " >> ] >> >> I just uploaded this example and also how to write doubles from/to memory. >> See at SqS/NativeBoost - NativeBoost-Examples package, class NBBasicExamples. >> >>> I am very comfortable adding functions to a library for integer and float/double calculations on "large" arrays and calling them via FFI; plugins are another story. Are there examples to follow? >> >> Tell me, what examples you would like to see. I will gladly provide them. >> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] >>> Sent: Wednesday, September 22, 2010 6:20 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] DoubleArray >>> >>> On 23 September 2010 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> Henry, >>>> >>>> I have been getting away with #doubleAt: and #doubleAt:put:, and otherwise doing pretty much what you said, though I just use a byte array to hold the data. It seems to work; for FFI, I end up passing void pointers instead of double pointers, which I don't like doing. >>>> >>>> Your point about using ordinary arrays makes sense to a point, though even w/o external interfacing, there is still a use for DoubleArray just as there is a use for String vs. an array of characters. >>>> >>> >>> The main reason, why they are not here, that VM needs an additional >>> set of primitives, which working with them. >>> >>> <sellsman hat on> >>> I can only say that with NativeBoost, you could be able to implement >>> it quite easily in image and ship it in image, >>> without a need to change VM or use external plugin. >>> <sellsman hat off> >>> >>>> Bill >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] >>>> Sent: Wednesday, September 22, 2010 5:23 PM >>>> To: pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] DoubleArray >>>> >>>> On 22.09.2010 23:09, Schwab,Wilhelm K wrote: >>>>> Squeak, deliberately, does not have a double array class. Is that because there is some horrible reason it can't work, or because it won't work on certain platforms? >>>> If the goal is to pass it as a parameter to an external function, one >>>> way would be to subclass WordArray, storing(and reading) each Float in >>>> two elements, and have the endianness decided by Smalltalk endianness. >>>> Probably want a startUp method for the class to swap instances >>>> endianness if the platform has changed as well. >>>>> Put another way, should we add such a class, if only via an external heap or whatever would be needed to make it reliable? >>>>> >>>>> Bill >>>> More likely because no one has actually had a need for one. >>>> It's definitely not _needed_ in base, where normal arrays of floats >>>> would do the same job just as well, if not better. >>>> IMHO, if someone makes one, it so should probably be part of a package >>>> related to external interfacing. >>>> >>>> Cheers, >>>> Henry >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

4 7

[Pharo-project] NativeBoost examples (was: Re: DoubleArray)
by Igor Stasenko Sept. 23, 2010

Sept. 23, 2010

On 23 September 2010 02:00, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Fair enough :) Â The most recent thing I recall on NativeBoost is Stef asking for what I assume must be a Mac plugin; I thought Linux would be left out too, but it appears not, though it is not in my current vm. Â Beyond some list traffic, I found this: > The work for supporting Linux and Mac is in progress. > Â http://code.google.com/p/nativeboost/wiki/NativeBoost > > Is there other documentation somewhere? Â Build instructions? You can find all existing documentation, installation instructions on wiki pages at the above site. There is no other place for it. http://code.google.com/p/nativeboost/wiki/Installation - installation instructions. > You have a block copy, which is good. Â What about indexing, such as getting floats or doubles out of external memory? This is just a piece of cake. ;) readDoubleFrom: address " This method loads the double from given external address. an address can be an instance of NBExternalAddress, or simple ByteArray with at least 8 bytes long, which holds a double floating value" <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> "We are using a pseudo-function prototype and supplying own assembler code, instead of making a call to external function. In given example, an address argument , after coercion is pushed on stack. " ^ NBFFICallout cdecl: #( double ( void * address) ) " A pseudo-function takes 1 argument, and returns double value. Under cdecl call convention, all floating point return types is returned in fp(0) CPU register" emitCall: [:gen | | asm | asm := gen asm. "Here , we expecting that an address value is already pushed on stack" asm pop: asm EAX; "load an address value into EAX register by popping a stack" fld: (asm EAX ptr64). "load a floating point value from memory, at base address, held in EAX register into fp(0) register, we are using #ptr64, to indicate that memory operand size is 64bits long" " return value set, we are done. A code generator will take care for emitting code, which converts a double floating point value into smalltalk object. " ] I just uploaded this example and also how to write doubles from/to memory. See at SqS/NativeBoost - NativeBoost-Examples package, class NBBasicExamples. > I am very comfortable adding functions to a library for integer and float/double calculations on "large" arrays and calling them via FFI; plugins are another story. Â Are there examples to follow? Tell me, what examples you would like to see. I will gladly provide them. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Wednesday, September 22, 2010 6:20 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] DoubleArray > > On 23 September 2010 00:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Henry, >> >> I have been getting away with #doubleAt: and #doubleAt:put:, and otherwise doing pretty much what you said, though I just use a byte array to hold the data. Â It seems to work; for FFI, I end up passing void pointers instead of double pointers, which I don't like doing. >> >> Your point about using ordinary arrays makes sense to a point, though even w/o external interfacing, there is still a use for DoubleArray just as there is a use for String vs. an array of characters. >> > > The main reason, why they are not here, that VM needs an additional > set of primitives, which working with them. > > <sellsman hat on> > I can only say that with NativeBoost, you could be able to implement > it quite easily in image and ship it in image, > without a need to change VM or use external plugin. > <sellsman hat off> > >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] >> Sent: Wednesday, September 22, 2010 5:23 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] DoubleArray >> >> Â On 22.09.2010 23:09, Schwab,Wilhelm K wrote: >>> Squeak, deliberately, does not have a double array class. Â Is that because there is some horrible reason it can't work, or because it won't work on certain platforms? >> If the goal is to pass it as a parameter to an external function, one >> way would be to subclass WordArray, storing(and reading) each Float in >> two elements, and have the endianness decided by Smalltalk endianness. >> Probably want a startUp method for the class to swap instances >> endianness if the platform has changed as well. >>> Put another way, should we add such a class, if only via an external heap or whatever would be needed to make it reliable? >>> >>> Bill >> More likely because no one has actually had a need for one. >> It's definitely not _needed_ in base, where normal arrays of floats >> would do the same job just as well, if not better. >> IMHO, if someone makes one, it so should probably be part of a package >> related to external interfacing. >> >> Cheers, >> Henry >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

2 3

Re: [Pharo-project] decompiledSource
by StÃ©phane Ducasse Sept. 23, 2010

Sept. 23, 2010

herve if the suggestion of henrik does not help you let us know what kind of crazy stuff you are doing :) Stef On Sep 23, 2010, at 2:15 PM, Henrik Johansen wrote: > > On Sep 23, 2010, at 1:35 18PM, Herve Verjus wrote: > >> Hello All, >> >> I would like to port some VisualWorks code into Pharo. The VW current project code uses VW Kernel.decompiledSource that does not seem to be implemented in Pharo...Is there a Pharo method that does the same...Is there someone with an idea ? >> >> Thank you... >> >> Herve > If you mean CompiledBlock/CompiledCode #decompiledSource, I think the equivalent in Pharo would be BlockClosure / CompiledMethod #decompile > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] HashedCollection showstopper :(
by Igor Stasenko Sept. 23, 2010

Sept. 23, 2010

Unfortunately, when preparing new finalization stuff, i got stuck with HashedCollection which is not yet integrated to Pharo. (Sets with nils also depending on that). In Squeak, old WeakRegistry does the trick by setting a #finalizer: to WeakKeyDictionary instance. Levente, can i ask you to give me a bits, (changesets or mcz packages), which contain HashedCollection refactorings. Or, we can follow an easier path, just extract the delta from two packages, which i found in mail archives: --- I uploaded two packages which contain this change. To load it evaluate the following: (Installer squeakfoundation project: 'inbox') install: 'Collections-ul.310.mcz'; install: 'Collections-ul.311.mcz' --- these are only related to WeakKeyDictionary, made by Levente to speedup old finalization. -- Best regards, Igor Stasenko AKA sig.

2 2

[Pharo-project] [ANN] JQueryWidgetBox 1.5 for Seaside 3.0
by Torsten Bergmann Sept. 23, 2010

Sept. 23, 2010

Hi there, version 1.5 of the "JQueryWidgetBox" project [1] is available for Seaside 3.0. There are now 32 interesting JQuery widgets wrapped that you can easily use in your Seaside applications. Most noteably we now have a wrapper for mbMenu [2] and uilayout [3]. Also a jQuery Grid is included. I updated some scripts and after some adoptions of existing packages all 81 tests went green again. Thanks to all who helped wrapping the jquery widgets out there!!! To try: ======= Open a clean Pharo 1.1. image and evaluate: Gofer new squeaksource:'MetacelloRepository'; package:'ConfigurationOfJQueryWidgetBox'; load. ((Smalltalk at: #ConfigurationOfJQueryWidgetBox) project version: '1.5') load. You can now load some additional Seaside tools by evaluating: ((Smalltalk at: #ConfigurationOfSeaside30) project version: '3.0.0-rc') load: #('Seaside-Pharo-Tools-OmniBrowser' 'Seaside-Adaptors-Comanche') Now select "Tools -> SeasideControl Panel" to open the control panel. Using the context menu add an WAComancheAdaptor and start it. Now point your browser to http://localhost:8080/browse/jquery-widgets Bye T. [1] http://squeaksource.com/JQueryWidgetBox.html [2] http://pupunzi.open-lab.com/mb-jquery-components/mb-_menu/ [3] http://layout.jquery-dev.net -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl

1 0

[Pharo-project] Metacello repositories in the future
by Torsten Bergmann Sept. 23, 2010

Sept. 23, 2010

One thing I think that should be discussed at ESUG (sorry I'm not there) is if and how we want to maintain Metacello repositories for the different Pharo versions in the future. I still think about the project/repo dependency issue: An example: we have a repo for Pharo 1.2: MetaRepoForPharo12 it may contain a ConfigurationOfFFI that works for Pharo 1.1. and loads FFI. it may also contain a ConfigurationOfExternalBrowser that requires the ConfigurationOfFFI (usual Metacello project dependency) When Pharo 1.3 comes out we have a new MetaRepoForPharo13 and may just copy ConfigurationOfFFI over since it only loads packages and these packages may be compatible to Pharo 1.3. So far so good ... but: What about ConfigurationOfExternalBrowser, if we just copy it to the new repo the config still points to the "old" ConfigurationOfFFI in the old MetaRepoForPharo12 repo and not to the new one in MetaRepoForPharo13. So we will have to adopt the configs for any new platform version ... and since world keeps spinnning we may also end up with forked configurations. Bye T. -- GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl

7 7

[Pharo-project] News on Mondrian
by Alexandre Bergel Sept. 23, 2010

Sept. 23, 2010

Hi! I am please to announce that Mondrian now includes an help and tutorial. These are accessible from the Easel menu and the World menu (help item). You can load Mondrian with: Gofer new squeaksource: 'Mondrian'; package: 'ConfigurationOfMondrian'; load. (Smalltalk at: #ConfigurationOfMondrian) perform: #loadDefault. I would be please to hear feedback on them. The PharoByExampleV2 chapter on Mondrian will be based on the tutorial. I am currently working on a Tutorial->Latex importer. What I did in the plane on the way back form esug. 582: No leaf class is abstract. Move down some methods from MOShape to MONodeShape 581: Help and tutorial finished. Added some new test and renamed a few things 580: easel examples are better commented and more descriptive 579: Added submenu in Easel help 578: MOAnnouncer>>forward: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

Re: [Pharo-project] [Vm-dev] failing/errors Pharo Tests with CogVM
by Mariano Martinez Peck Sept. 23, 2010

Sept. 23, 2010

Ok....that's to all the responses. The thread is now far away my knoweldege, so I will naively ask: is it worth creating a Pharo 1.1.1 one click with CogVM? Marcus released a PharoCore 1.1.1 with changes for CogVM and some important fixes. I took that core image and I created a new dev. But before releasing, I run the tests and I found them. Seems you all discussed about the Float problems...but what about the others? I remember them and I thing they were fixed in newest versions of VMMaker. So...the question is now....are the failure/error of those tests means that Pharo is "unreleasable" with CogVM? Should we wait for the fix or we should release anyway? Thanks in advance, Mariano On Fri, Sep 17, 2010 at 8:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Thu, Sep 16, 2010 at 10:54 PM, Andreas Raab <andreas.raab(a)gmx.de>wrote: > >> >> On 9/16/2010 2:44 PM, Eliot Miranda wrote: >> >>> I realise we need to be more precise. Are you talking about NaNs >>> specifically or NaN and Inf? >>> >> >> NaN only. +-Inf are fine as they have a well-defined mathematical >> relationship over the set of numbers. NaN does not. >> >> >> The Squeak VM happily answers Inf from its >>> float primitives. In fact the only guard against a NaN or Inf result >>> being produced by the floating-point primitives is the guard against >>> dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300) >>> isInfinite and there is no failure. So specifically failing for aFloat >>> / 0.0 seems a bit of a fig leaf to me. >>> >>> So what would your ideal semantics be? >>> a) - fail whenever the result is Inf or NaN? >>> b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf >>> c) - fail whenever the result is NaN but fail aFloat / 0.0 >>> d) - the Interpreter status quo, fail only for aFloat / 0.0 >>> e) - never fail and answer Nan and Inf as specified in IEEE 754 >>> >>> The situation with VW before IEEE was that it did a) and we changed it >>> so that the mode switch selected either a) or e), with, IIRC, the >>> current default being e). >>> >> >> f) Fail whenever the result is NaN or when dividing by zero. >> > > OK, to be pedantic that's c) above. But fine. This is a reasonable choice. > > >> My preference for f) is that division by zero should be consistent between >> floating point numbers and integers. It would be strange if "1 / 0" => boom >> but "1.0 / 0" => Inf or "1 / 0.0" => Inf. *However* underflow isn't division >> by zero and may silently result in Inf. In other words: >> >> self should:[1.0 / 0.0] raise: ZeroDivide. >> >> but (#successor produces the smallest float larger than the receiver) >> >> self shouldnt:[1.0 / 0.0 successor] raise: Error. >> self assert: (1.0 / 0.0 successor) = Float infinity. >> >> Cheers, >> - Andreas >> > > >

1 1