In addition, open addressing with linear probing has superior cache line
read behavior (no indirection / random traversal, and if the first probe
misses the second one was likely cached by the first one).
On 6/8/18 1:37 , Levente Uzonyi wrote:
On Fri, 8 Jun 2018, Clément Bera wrote:
Hi Max,
Because by definition, a floating point value is of the form
+/- 2^e * m
for some 0 <= m < M, and e in some range of values (some positive, some
negative). There are other special cases that don't matter here, such
as NaN, INF, denormals, etc.
So now set up the equality you want. Since
Martin,
On 1/30/17 16:41 , Martin McClure wrote:
IEEE-754 does not define a "sign" operation. ANSI Smalltalk and ISO/IEC
10967 do, so it makes sense to provide a #sign that conforms to those
standards -- answering -1, 0, or 1.
IEEE-754 does define an isSignMinus operation, answering true or
The 2007 update of 10967 is somewhat more helpful. It replaces the
"sign" operation with one called "signum" which returns 1, -1, or NaN.
It returns 1 for positive zero and positive infinity, and -1 for
negative zero and negative infinity. If given a qNaN, it returns a qNaN.
If given a signaling
Hey Martin... I agree on the confusion.
> I still recommend not rounding the number itself, but
rounding the printing of the number
Yes.
If "rounding" had well specified behavior that was at least somewhat
reasonable (e.g. return the closest floating point value and round to
even if tied),
self ffiCall: #(int printf(String format, int number))
that will work… yes is not the best in the word, but it works :)
Esteban
On 23 Sep 2016, at 08:11, Andres Valloud <avall...@smalltalk.comcastbiz.net>
wrote:
I wouldn't do that if I were you. The manual says fcntl() can be a
I wouldn't do that if I were you. The manual says fcntl() can be a
macro, and you can't call a macro from an FFI.
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/fcntl.h.html
On 9/22/16 15:12 , Mariano Martinez Peck wrote:
Hi guys,
I am wondering if I can wrap some variadic
Hi! Your Camp Smalltalk crew has been at it for a while, and we are
very happy to announce a Camp Smalltalk at Marquette, Michigan, on
September 15-18th. The event's website is at http://mqt.st. We are
generously hosted by Northern Michigan University (http://www.nmu.edu),
where John Sarkela
Also FYI the Pharo Consortium's website at http://consortium.pharo.org/
displays a Proxy Error.
On 8/5/16 7:35 , Esteban A. Maringolo wrote:
Hi all,
The Pharo website doesn't work properly if you access it vía HTTPS
(and Chrome), apparently some resources (JS and CSS) are explicitly
linked to
The Fundación Argentina de Smalltalk proudly invites you to one of the
premier Smalltalk conferences in the world. Let's meet at Buenos Aires,
November 11-13! For more details, see the invitation here:
http://www.fast.org.ar/Smalltalks2015-invitation.pdf
Camp Smalltalk Portland 2015 is go for August 21st through the 23rd!
(and if you arrive earlier on the 20th that's cool too) Please register
for the event here:
https://www.picatic.com/event14352674835773927
Help us by filling in the questions so you can get your event shirt. And
also see
A group of Smalltalkers have been discussing the possibility of
having a Camp Smalltalk in Portland Oregon, August 20-23. If you
think you might be interested in attending such a gathering, please
let us know filling our short survey:
http://goo.gl/forms/Di0rFPMcLu
Side comments...
Some code just has to be written in C, otherwise you cannot rely on the
behavior being correct and ultimately that's a major show stopper for
anything you might want to call production code. Anything having to
do with calling operating system libraries is a typical example
1. Invitation.
The Fundación Argentina de Smalltalk (FAST, http://www.fast.org.ar)
invites you to the 8th International Conference on Smalltalk
Technologies (Smalltalks), to be held from November 5th through
November 7th at the Universidad Tecnológica Nacional,
LARGEADDRESSAWARE, so more memory
space is enabled for 64bits Windows OSs.
Thanks guys
Oscar
On Thu, Jul 17, 2014 at 11:03 PM, Andres Valloud
avall...@smalltalk.comcastbiz.net
mailto:avall...@smalltalk.comcastbiz.net wrote:
I worked on that switch before, and IIRC it's just
Does the VM make a single memory allocation to load the image file?
On 7/19/14 17:20 , Ben Coman wrote:
Andres Valloud wrote:
Keep in mind that, depending on how images are loaded, you won't be
able to load images larger than about 2gb... you might want to test that.
Can you hint what those
I worked on that switch before, and IIRC it's just a linker switch that
marks executables a certain way. So, if you have imagecfg.exe handy...
http://support.microsoft.com/kb/297812
On 7/17/14 19:25 , Oscar E. A. Callaú wrote:
Well. It seems that Pharo vms must be compiled with that option
/LARGEADDRESSAWARE?... I don't think /3GB is even recognized in 64 bit
Windows...
http://support.microsoft.com/default.aspx?scid=889654
On 7/16/14 14:49 , Eliot Miranda wrote:
On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. Callaú
oscar.apo...@gmail.com mailto:oscar.apo...@gmail.com wrote:
not round true or false to the
nearest float, so it's even nicer!
On 7/11/14 17:19 , Nicolas Cellier wrote:
2014-07-12 1:29 GMT+02:00 Andres Valloud
avalloud@smalltalk.__comcastbiz.net
mailto:avall...@smalltalk.comcastbiz.net
mailto:avalloud@smalltalk
difference is that we do not round true or false
to the
nearest float, so it's even nicer!
On 7/11/14 17:19 , Nicolas Cellier wrote:
2014-07-12 1:29 GMT+02:00 Andres Valloud
avalloud@smalltalk.__comcastb__iz.net
http
I don't think it makes sense to compare floating point numbers to other
types of numbers with #=... there's a world of approximations and other
factors hiding behind #=, and the occasional true answer confuses more
than it helps. On top of that, then you get x = y = x hash = y hash,
and so
I don't think it makes sense to compare floating point numbers to
other types of numbers with #=... there's a world of approximations
and other factors hiding behind #=, and the occasional true answer
confuses more than it helps. On top of that, then you get x = y =
x hash =
Sp, speaking of mathematical precedence and all that, anyone up to
looking at the IEEE-754 spec and making one's Smalltalk of choice comply
with _all_ the requirements? Or how about implementing decimal floats?
On 6/26/14 12:01 , p...@highoctane.be wrote:
Couldn't we just have an expression
Hey Philippe,
Yes but #= is blissfully unaware of normalization in Squeak/Pharo. In
fact AFAIK Squeak/Pharo is unaware of normalization. Having a short look
at it doesn't even look as if case insensitivity worked in Squeak/Pharo
outside of Latin-1 (I could be wrong though).
Yes, that's what I
What is going to happen when one compares two general Unicode series of
characters that represent the same string but differ in normalization?
Wouldn't the size test would result in false negatives?
http://unicode.org/reports/tr15/
I'm asking because I haven't seen any discussion on the
* 64-bit aware hashing functions as the current ones are 32-bit centric.
This issue might not be the most urgent because the 32 bit hash
functions should be sufficient to deal with at least moderately sized 64
bit images. But how much stuff would you have to allocate before seeing
a
Hey Doru, I was going to ask so is that a language or a library?...
On 4/1/14 23:12 , Tudor Girba wrote:
Indeed, I read this article several times over the last couple of days.
This work is impressive particularly when combined with the cloud part.
The language itself is less interesting for
So it seems the problem is with Fuel rather than IdentitySet, no?
On 3/2/14 10:47 , Max Leske wrote:
During serialization the IdentitySet size is stored and later its objects.
During that step, #do:
So, just out of curiosity, how does the IdentitySet get damaged?
On 3/2/14 11:28 , Max Leske wrote:
On 02.03.2014, at 20:12, Andres Valloud avall...@smalltalk.comcastbiz.net
wrote:
So it seems the problem is with Fuel rather than IdentitySet, no?
No. Asking an IdentitySet for its size
AM, Andres Valloud
avall...@smalltalk.comcastbiz.net
mailto:avall...@smalltalk.comcastbiz.net wrote:
Hello...
On 2/25/14 1:17 , p...@highoctane.be mailto:p...@highoctane.be
wrote:
I am currently reading through the Hashing in Smalltalk book
Hello...
On 2/25/14 18:32 , Martin McClure wrote:
Andres and I have an ongoing discussion on this topic. :-)
:)...
And #bitShift *should* be faster.
Ok, but how much faster? 64x64 bit multiplication on modern x86 is just
8 cycles (!), and there will likely be parallelism done by the
all of the mapping phase results to
the reduce nodes. I am surprised to see that Smalltalk vendors haven't
jumped in that space.
Phil
On Wed, Feb 26, 2014 at 2:04 AM, Andres Valloud
avall...@smalltalk.comcastbiz.net
mailto:avall...@smalltalk.comcastbiz.net wrote:
Hello...
On 2/25/14 1
Hello...
On 2/25/14 1:17 , p...@highoctane.be wrote:
I am currently reading through the Hashing in Smalltalk book
(http://www.lulu.com/shop/andres-valloud/hashing-in-smalltalk-theory-and-practice/paperback/product-3788892.html)
and, my head hurting notwithstanding, there are indeed a ton
On 2/16/14 3:38 , Levente Uzonyi wrote:
On Sat, 15 Feb 2014, Alejandro Infante wrote:
Well, I tried today using that to release some memory used by
Roassal. Let's say all the instances of ROElement. So I executed
the following code:
ROElement allInstances do: [:el | el becomeForward: nil ].
FYI writing any decent production quality tool takes way more than 1
hour. IME writing *two* reference finders, it takes a bunch of effort
to make them work correctly, reliably, quickly, and in a useful way.
On 2/15/14 6:31 , Alexandre Bergel wrote:
Well... I do no think so. There is a fair
can't really do becomeForward: (or
it won't help), e.g. with a class (this would fall under the reliably
category).
We are all capable of writing random workspace code, I don't think this
is the idea for these projects.
On 2/15/14 16:34 , Levente Uzonyi wrote:
On Sat, 15 Feb 2014, Andres Valloud
Whoops, it was an old bug after all! :(
On 1/13/14 4:51 , Nicolai Hess wrote:
Yes, chaging the system time is a known issue for pharos linux-vm:
11324 https://pharo.fogbugz.com/default.asp?11324 Image freeze when
changing system time
?
There have been mysterious time(r) related problems in the past, it would be
good to follow up on something concrete and repeatable.
Thx,
Sven
On 12 Jan 2014, at 04:41, Andres Valloud avall...@smalltalk.comcastbiz.net
wrote:
Somewhat related only, but FYI something I've noticed with Cog VMs
confirm that same problem exists in pharo-vm
with pharo-image?
Esteban
On 13 Jan 2014, at 09:37, Andres Valloud avall...@smalltalk.comcastbiz.net
wrote:
Try the following on OS X...
1. Launch Pharo (Cuis).
2. Go to the System Settings time panel.
3. Disable automatic time updates.
4. Bump
(of course, make sure you're online when you re-enable automatic time
keeping so that NTP bumps the clock backwards... if not, do it manually)
On 1/13/14 4:10 , Andres Valloud wrote:
My friend, you need to believe :)...
Ok, so with Cuis the image hangs (unresponsive to input) when the clock
My friend, you also need to believe :)...
Checked with Pharo 3.0, misbehavior reproduced.
I'm done hanging various versions of Pharo and Cuis on my machine. It's
someone else's turn now :D.
On 1/13/14 4:17 , Marcus Denker wrote:
On 13 Jan 2014, at 13:10, Andres Valloud avall
Somewhat related only, but FYI something I've noticed with Cog VMs is
that if you bump the computer clock forward by e.g. 30 seconds then Cuis
remains frozen for 30 seconds. Under the assumption that Cuis and Pharo
are close enough, and considering that alt+. does not bring up a
debugger
Check out the playlist here:
http://www.youtube.com/playlist?list=PLCGAAdUizzH027lLWKXh_44cGuEsay7-R
Make sure you don't miss Smalltalks 2014!
Andres.
Well, maybe, although it's interesting to consider how many strings
streams need to beat string concatenation. Moreover, streams aren't
hyper efficient either...
On 11/16/13 10:09 , b...@openinworld.com wrote:
Code Critic rule Optimization String concatenation instead of streams
says:
The details really don't fit in an email, however the 2nd volume of my
Fundamentals book already has an analysis of this issue and hence my
previous comment.
On 11/17/13 8:45 , Stéphane Ducasse wrote:
this one is surprising to me
[ 'foo', 'bar', 'baz', 'foobar' ] bench. '2,030,000 per
We’re only measuring execution speed, not memory allocation, which is important
too.
Yes. And besides having to collect the garbage at some point,
allocation can be costly because the VM has to zero out the string bytes
(or nil them if the string is not encoded) and then write on those
Are you saying the Pharo VM requires glibc version 2.15 of March 2012,
and that consequently the Pharo VM as compiled won't run on any Linux
distro older than 17 months?
On 8/8/13 5:52 , Igor Stasenko wrote:
Yes. It is known issue.
Now there's little we can do, except from building VM for
47 matches
Mail list logo
