- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NB Types and C Types

by Jimmie Houchin

On 12/15/2012 6:00 AM, Igor Stasenko wrote: > On 14 December 2012 20:48, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> Hello, >> >> In my app using NB and have a few questions on types. >> >> In one function I have an size_t *arg >> for an argument. Is NBUInt64 proper for this argument? > No. 'size_t*' is a pointer. > A size_t type defined as an unsigned integer type, with range big > enough to specify size(s) > like array size, or a size of memory to allocate in bytes. > On 32-bit systems size_t is unsigned 32-bit integer. > > And here how you can answer your question by yourself: > > NBFFICallout new resolveType: 'size_t*' >> I also have a DATE which uses OLE Automation date format which is described >> as: >> >> """ >> An OLE Automation date is implemented as a floating-point number whose >> integral component is the number of days before or after midnight, 30 >> December 1899, and whose fractional component represents the time on that >> day divided by 24. >> """ >> >> Would NBUInt64 be best or is NBUInt32 a better fit? I haven't seen a method >> for this particular date epoch, but I can easily write the method to handle >> conversion. > No. The C double type has a special discipline for returning it from function: > - it is returned in FP register, unlike rest which using EAX/EDX registers. > So, if you use either NBUInt64 or NBUInt32 you won't be able to get > actual values which function returns. > > So, you should use 'double' type, which is alias for NBFloat64 Thank you very much for this reply. Educating me and everyone else on the NBFFICallout new resolveType: 'size_t*' It will come in handy. I don't know why I typed NBUInt64/32 for the double. I had NBFloat64 in my code. I must have had it on my mind from the first question. I Googled for both of these before inquiring. I saw debates on the size of the size_t type. I just wanted confirmation and it seems it was necessary. Again thanks. Jimmie

Dec. 16, 2012

Re: [Pharo-project] CI down?

by StÃ©phane Ducasse

On Dec 16, 2012, at 5:24 PM, Max Leske wrote: > ah, thanks. > > I wanted to update the links on the pharo-project page but there's stuff missing (or I don't know where it is), e.g. the one-click build and the vm zips (from the dedicated download server). We should change everything. Now we are waiting that the inria service really open (currently in beta) and at the same time we saturated our disc space so we had to kill the old integration server. Stef

Dec. 16, 2012

[Pharo-project] [update 2.0] #20436

by StÃ©phane Ducasse

20436 ----- Issue 7111: showing problem with extending packages http://code.google.com/p/pharo/issues/detail?id=7111 So I integrated the recategorization of Job in Kernel-Job ProgressBar in Morphic-ProgressBar + adding comments + improving a bit ProgressBar. Diff information: http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.743.di… http://ss3.gemstone.com/ss/Pharo20/Morphic-StephaneDucasse.1307.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-StephaneDucasse.1268.diff http://ss3.gemstone.com/ss/Pharo20/Deprecated20-StephaneDucasse.26.diff Stef

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by StÃ©phane Ducasse

On Dec 16, 2012, at 5:33 PM, Frank Shearar wrote: > On 16 December 2012 16:19, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Beware, Range exists in other languages (python, etc..). >> We should check if they correspond to a Smalltalk Interval or a >> mathematical Interval. >> If they correspond to a Smalltalk Interval, that will be one more >> un-necessary trap. > > Certainly in Ruby a range is like a Smalltalk Interval: (1..10) is the > same as 1 to: 10. can they do not real intersection with ] [ and [ ] stef > >> Note that we rarely use Interval, we just use #to: or #to:by:, so we >> could as well rename Interval->Range. >> And postpone creation of Mathematical Interval which is most likely >> unused in kernel image. > > Indeed, I think it's clear the confusion around this class is as Igor > says: a mathematical interval, or a set of contiguous integers (or > other countable things). > > frank > >> Nicolas >> >> 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> I agree so we should introduce Range. >>> Did not you or camillo started to have Range? >>> It can be a really nice class. >>> >>> Stef >>> On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: >>> >>>> So, to my sense a behavior of Interval is overloaded.. >>>> it tries to be too many things at once: >>>> - be an interval in math sense (which is infinite set if used for Real numbers) >>>> - be a "collection" of numbers which you can enumerate (implies that >>>> it is finite). >>>> >>>> to me, i would be much happier if we could have two different and >>>> non-intersecting entities: >>>> >>>> - Enumeration. This one indeed can be used as a collection. i.e. >>>> "give me all integer numbers lying between values A and B, count each >>>> C-th number" >>>> Like that, >>>> (1 to: 1.5 by: 1) is enumeration which contains a single element. >>>> and #last should be = 1 >>>> >>>> - Interval (Range). A pure interval in math sense: defines a Set of >>>> numbers lying between numbers A and B, inclusive, where A <= B. Not >>>> enumerable, therefore no 'step' variable, instead what it could have, >>>> is flags to indicate whether interval endpoints included into interval >>>> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. >>>> >>>> Not supporting enumeration (no #do: , no #add: no #at: etc). You can, >>>> however intersect, merge or diff two intervals etc.. same operations >>>> which you doing on sets (but that would require another entity - >>>> interval set). And of course, you can test whether some number lies >>>> within given interval or not. >>>> >>>> The reason i started this topic is because some code were using >>>> 'range' for variables which holding intervals.. >>>> Now what you think is more appropriate protocol for something called >>>> 'range', this: >>>> >>>> x := range first >>>> y := range last >>>> >>>> or this: >>>> >>>> x := range start >>>> y := range end >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by StÃ©phane Ducasse

> Beware, Range exists in other languages (python, etc..). > We should check if they correspond to a Smalltalk Interval or a > mathematical Interval. > If they correspond to a Smalltalk Interval, that will be one more > un-necessary trap. > > Note that we rarely use Interval, we just use #to: or #to:by:, so we > could as well rename Interval->Range. > And postpone creation of Mathematical Interval which is most likely > unused in kernel image. Why not? Now it would be good to move. but what I know is that igor wanted to have range intersection for the new text model. Another question: who thinks that ruby look at Smalltalk when they take a decision on their library? I do not think so. We can check what is around and **improve** our nice system Stef > 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I agree so we should introduce Range. >> Did not you or camillo started to have Range? >> It can be a really nice class. >> >> Stef >> On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: >> >>> So, to my sense a behavior of Interval is overloaded.. >>> it tries to be too many things at once: >>> - be an interval in math sense (which is infinite set if used for Real numbers) >>> - be a "collection" of numbers which you can enumerate (implies that >>> it is finite). >>> >>> to me, i would be much happier if we could have two different and >>> non-intersecting entities: >>> >>> - Enumeration. This one indeed can be used as a collection. i.e. >>> "give me all integer numbers lying between values A and B, count each >>> C-th number" >>> Like that, >>> (1 to: 1.5 by: 1) is enumeration which contains a single element. >>> and #last should be = 1 >>> >>> - Interval (Range). A pure interval in math sense: defines a Set of >>> numbers lying between numbers A and B, inclusive, where A <= B. Not >>> enumerable, therefore no 'step' variable, instead what it could have, >>> is flags to indicate whether interval endpoints included into interval >>> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. >>> >>> Not supporting enumeration (no #do: , no #add: no #at: etc). You can, >>> however intersect, merge or diff two intervals etc.. same operations >>> which you doing on sets (but that would require another entity - >>> interval set). And of course, you can test whether some number lies >>> within given interval or not. >>> >>> The reason i started this topic is because some code were using >>> 'range' for variables which holding intervals.. >>> Now what you think is more appropriate protocol for something called >>> 'range', this: >>> >>> x := range first >>> y := range last >>> >>> or this: >>> >>> x := range start >>> y := range end >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Frank Shearar

On 16 December 2012 16:19, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Beware, Range exists in other languages (python, etc..). > We should check if they correspond to a Smalltalk Interval or a > mathematical Interval. > If they correspond to a Smalltalk Interval, that will be one more > un-necessary trap. Certainly in Ruby a range is like a Smalltalk Interval: (1..10) is the same as 1 to: 10. > Note that we rarely use Interval, we just use #to: or #to:by:, so we > could as well rename Interval->Range. > And postpone creation of Mathematical Interval which is most likely > unused in kernel image. Indeed, I think it's clear the confusion around this class is as Igor says: a mathematical interval, or a set of contiguous integers (or other countable things). frank > Nicolas > > 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I agree so we should introduce Range. >> Did not you or camillo started to have Range? >> It can be a really nice class. >> >> Stef >> On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: >> >>> So, to my sense a behavior of Interval is overloaded.. >>> it tries to be too many things at once: >>> - be an interval in math sense (which is infinite set if used for Real numbers) >>> - be a "collection" of numbers which you can enumerate (implies that >>> it is finite). >>> >>> to me, i would be much happier if we could have two different and >>> non-intersecting entities: >>> >>> - Enumeration. This one indeed can be used as a collection. i.e. >>> "give me all integer numbers lying between values A and B, count each >>> C-th number" >>> Like that, >>> (1 to: 1.5 by: 1) is enumeration which contains a single element. >>> and #last should be = 1 >>> >>> - Interval (Range). A pure interval in math sense: defines a Set of >>> numbers lying between numbers A and B, inclusive, where A <= B. Not >>> enumerable, therefore no 'step' variable, instead what it could have, >>> is flags to indicate whether interval endpoints included into interval >>> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. >>> >>> Not supporting enumeration (no #do: , no #add: no #at: etc). You can, >>> however intersect, merge or diff two intervals etc.. same operations >>> which you doing on sets (but that would require another entity - >>> interval set). And of course, you can test whether some number lies >>> within given interval or not. >>> >>> The reason i started this topic is because some code were using >>> 'range' for variables which holding intervals.. >>> Now what you think is more appropriate protocol for something called >>> 'range', this: >>> >>> x := range first >>> y := range last >>> >>> or this: >>> >>> x := range start >>> y := range end >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >

Dec. 16, 2012

Re: [Pharo-project] CI down?

by Max Leske

ah, thanks. I wanted to update the links on the pharo-project page but there's stuff missing (or I don't know where it is), e.g. the one-click build and the vm zips (from the dedicated download server). On 16.12.2012, at 16:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Try > > https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/artifact/ > > >> I wanted to grab the latest build to check for a possible bug and the CI seems to be downâ¦ >> >> Max > >

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Nicolas Cellier

Beware, Range exists in other languages (python, etc..). We should check if they correspond to a Smalltalk Interval or a mathematical Interval. If they correspond to a Smalltalk Interval, that will be one more un-necessary trap. Note that we rarely use Interval, we just use #to: or #to:by:, so we could as well rename Interval->Range. And postpone creation of Mathematical Interval which is most likely unused in kernel image. Nicolas 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I agree so we should introduce Range. > Did not you or camillo started to have Range? > It can be a really nice class. > > Stef > On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: > >> So, to my sense a behavior of Interval is overloaded.. >> it tries to be too many things at once: >> - be an interval in math sense (which is infinite set if used for Real numbers) >> - be a "collection" of numbers which you can enumerate (implies that >> it is finite). >> >> to me, i would be much happier if we could have two different and >> non-intersecting entities: >> >> - Enumeration. This one indeed can be used as a collection. i.e. >> "give me all integer numbers lying between values A and B, count each >> C-th number" >> Like that, >> (1 to: 1.5 by: 1) is enumeration which contains a single element. >> and #last should be = 1 >> >> - Interval (Range). A pure interval in math sense: defines a Set of >> numbers lying between numbers A and B, inclusive, where A <= B. Not >> enumerable, therefore no 'step' variable, instead what it could have, >> is flags to indicate whether interval endpoints included into interval >> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. >> >> Not supporting enumeration (no #do: , no #add: no #at: etc). You can, >> however intersect, merge or diff two intervals etc.. same operations >> which you doing on sets (but that would require another entity - >> interval set). And of course, you can test whether some number lies >> within given interval or not. >> >> The reason i started this topic is because some code were using >> 'range' for variables which holding intervals.. >> Now what you think is more appropriate protocol for something called >> 'range', this: >> >> x := range first >> y := range last >> >> or this: >> >> x := range start >> y := range end >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by StÃ©phane Ducasse

I agree so we should introduce Range. Did not you or camillo started to have Range? It can be a really nice class. Stef On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: > So, to my sense a behavior of Interval is overloaded.. > it tries to be too many things at once: > - be an interval in math sense (which is infinite set if used for Real numbers) > - be a "collection" of numbers which you can enumerate (implies that > it is finite). > > to me, i would be much happier if we could have two different and > non-intersecting entities: > > - Enumeration. This one indeed can be used as a collection. i.e. > "give me all integer numbers lying between values A and B, count each > C-th number" > Like that, > (1 to: 1.5 by: 1) is enumeration which contains a single element. > and #last should be = 1 > > - Interval (Range). A pure interval in math sense: defines a Set of > numbers lying between numbers A and B, inclusive, where A <= B. Not > enumerable, therefore no 'step' variable, instead what it could have, > is flags to indicate whether interval endpoints included into interval > or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. > > Not supporting enumeration (no #do: , no #add: no #at: etc). You can, > however intersect, merge or diff two intervals etc.. same operations > which you doing on sets (but that would require another entity - > interval set). And of course, you can test whether some number lies > within given interval or not. > > The reason i started this topic is because some code were using > 'range' for variables which holding intervals.. > Now what you think is more appropriate protocol for something called > 'range', this: > > x := range first > y := range last > > or this: > > x := range start > y := range end > > > -- > Best regards, > Igor Stasenko. >

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Igor Stasenko

So, to my sense a behavior of Interval is overloaded.. it tries to be too many things at once: - be an interval in math sense (which is infinite set if used for Real numbers) - be a "collection" of numbers which you can enumerate (implies that it is finite). to me, i would be much happier if we could have two different and non-intersecting entities: - Enumeration. This one indeed can be used as a collection. i.e. "give me all integer numbers lying between values A and B, count each C-th number" Like that, (1 to: 1.5 by: 1) is enumeration which contains a single element. and #last should be = 1 - Interval (Range). A pure interval in math sense: defines a Set of numbers lying between numbers A and B, inclusive, where A <= B. Not enumerable, therefore no 'step' variable, instead what it could have, is flags to indicate whether interval endpoints included into interval or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. Not supporting enumeration (no #do: , no #add: no #at: etc). You can, however intersect, merge or diff two intervals etc.. same operations which you doing on sets (but that would require another entity - interval set). And of course, you can test whether some number lies within given interval or not. The reason i started this topic is because some code were using 'range' for variables which holding intervals.. Now what you think is more appropriate protocol for something called 'range', this: x := range first y := range last or this: x := range start y := range end -- Best regards, Igor Stasenko.

Dec. 16, 2012