from:"Raffaello Giulietti"

On 2017-11-10 00:02, Henrik Sperre Johansen wrote:
> raffaello.giulietti wrote
>> On 2017-11-09 21:49, Stephane Ducasse wrote:
>>> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier
>>> <
> 
>> nicolas.cellier.aka.nice@
> 
>> > wrote:
 Note that this started a long time ago and comes up episodically
 http://forum.world.st/Fraction-equality-and-Float-infinity-problem-td48323.html
 http://forum.world.st/BUG-Equality-should-be-transitive-tc1404335.html
 https://lists.gforge.inria.fr/pipermail/pharo-project/2009-July/010496.html

 A bit like a "marronnier" (in French, a subject that is treated
 periodically
 by newspapers and magazines)
>>>
>>> Hi nicolas except that now we could a chapter describing some of the
>>> answers :)
>>>
>>
>> It's easy to make = behave as an equivalence if the two objects it
>> operates on are of the same class.
>>
>> But it is well-known that it's hard when their classes are different,
>> short of implementing = trivially in this case.
>>
>> This is to say that there's no real hope to make = an equivalence if the
>> wish is to make it useful in the presence of different kind of objects.
>>
>> In the context of numeric computations, luckily, there is some hope when
>> conversions, if possible at all, are all performed consistently. But the
>> same conversions should then be applied for all operations, whether
>> comparisons or subtractions, etc., to ensure more familiar properties.
>> This is not currently the case in Pharo.
>>
>>
>>
>> Raffaello
> 
> Personally, I rather like = being transitive across different types of
> objects, which is the case with the current implementation.* 
> It would not be if, like you suggest, multiple Fractions = the same Float.
> Take a moment to also reflect on what it would mean if, as the implication
> goes, a float represents a range of numbers on the rational number line,
> rather than a single point.
> Taken to its logical conclusion, it follows you'd need to also redefine the
> other mathematical operators to reflect this, as well as conversion to exact
> numbers like Integers and Fractions being lossy, rather than the other way
> around. 
> You could certainly build an interesting system of floats with such a
> property (I can swear I've read a paper on one somewhere...), but it
> wouldn't be the world of IEEE754 Floats we live in.
> 
> Other properties one might deem beneficial, such as 
> a + b > a if b > 0, 
> or  
> (a + b) + c = a + (b + c)
> are not true in the context of floats. Does that mean we need to fix them
> too?
> My 2c: It feels like you are asking Floats to be something they're not, and
> the answer simply isn't to try and paint over issues and try and make them
> look like something they're not.
> 
> Cheers,
> Henry
> 
> 

Personally, I could live without mixed arithmetic between unlimited and
limited precision numbers: I would always be explicit in the
conversions. They are so different in nature, like apples and oranges are.

This also entails that I would accept that 1 = 1.0 evaluates to false,
that 1 <= 1.0 throws an exception and all consequences of this.

But this would be unacceptable for most Smalltalkers for many good
reasons. And, as you point out, = and total ordering are easily
preserved if Floats are converted to Fractions. But then please convert
Floats to Fractions even when adding, multiplying, etc.

To me a Float does not stand for an interval. It's just a real number
that happens to have strange, unfamiliar operations that resemble the
pure ones. Some familiar properties also hold for these strange
operations, others do not.

Re: [Pharo-dev] float & fraction equality bug

On 2017-11-09 22:11, Nicolas Cellier wrote:
> 
> 
> 
> I think we have as much as possible already.
> Non equality resolve more surprising behavior than it creates.
> It makes the implementation more mathematically consistent
> (understand preserving more properties).
> Tell me how you are going to sort these 3 numbers:
> 
> {1.0 . 1<<60+1/(1<<60).  1<<61+1/(1<<61)} sort.
> 
> tell me the expectation of:
> 
> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size.
> 
> 
> A clearly stated rule, consistently applied and known to
> everybody, helps.
> 
> In presence of heterogeneous numbers, the rule should state the
> common denominator, so to say. Hence, the numbers involved in
> mixed-mode arithmetic are either all converted to one
> representation or all to the other: whether they are compared or
> added, subtracted or divided, etc. One rule for mixed-mode
> conversions, not two.
> 
> 
> Having an economy of rules is allways a good idea.
> If you can obtain a consistent system with 1 single rule rather than
> 2 then go.
> But if it's at the price of sacrificing higher expectations, that's
> another matter.
> 
> Languages that have a simpler arithmetic model, bounded integer, no
> Fraction, may stick to a single rule.
> More sofisticated models like you'll find in Lisp and Scheme have
> exact same logic as Squeak/Pharo.
> 
> sophisticated... (i'm on my way copying/pasting that one a thousand times)
> 
> We don't have 2 rules gratuitously as already explained.
> - Total relation order of non nan values so as to be a good
> Magnitude citizen imply non equality
> - Producing Float in case of mixed arithmetic is for practicle
> purpose: speed
>   (What are those damn Float for otherwise?)
>   it's also justified a posteriori by (exact op: inexact) -> inexact
> 
> What are you ready to sacrifice/trade?
> 
> 

Let me check if I correctly understand the reason for the dual rule
regime for mixed computations:

(1) preservation of = as an equivalence and of total ordering. This is
ensured by converting Floats to Fractions.

(2) performance in case of the 4 basic operations, which is the reason
for the second conversion rule from Fractions to Floats.

Now, the gain in speed by exercising (2) really depends on how the
numbers "mix" in a long chain of operations. I guess for most uses of
mixed arithmetic it doesn't make any noticeable difference with respect
to a pure Fraction computation. Besides, correctly converting a Fraction
to a Float requires more computation than the opposite.

So, to answer your question, if preservation of total order and = is
worthwhile even in case of mixed numbers, I would sacrifice speed for
the sake of the principle of least surprise. One rule, Float->Fraction,
slightly less speed.

But for those cases where the gain in speed from using Floats would make
a noticeable difference, we are entering the hard, counter-intuitive
realm of limited precision arithmetic anyway. We better be experts in
the first place. And as experts we will find a way out of the one-rule
regime by performing explicit Fraction->Float conversions where needed
and won't face surprises.

The only reason to prefer the opposite one-rule, that would always
convert Fractions to Floats in mixed computations, is compatibility with
the commercial Smalltalk implementations. Granted, it's not a sound
reason but a pragmatic one.

Re: [Pharo-dev] float & fraction equality bug

On 2017-11-09 22:11, Nicolas Cellier wrote:


> Something like exact difference like Martin suggested, then
> converting to nearest Float because result is inexact:
>  ((1/10) - 0.1 asFraction) asFloat
> 
> This way, you would have a less surprising result in most cases.
> But i could craft a fraction such that the difference
> underflows, and the assertion a ~= b ==> (a - b) isZero not
> would still not hold.
> Is it really worth it?
> Will it be adopted in other dialects?
> 
> 
> 
> As an alternative, the Float>>asFraction method could return the
> Fraction with the smallest denominator that would convert to the
> receiver by the Fraction>>asFloat method.
> 
> So, 0.1 asFraction would return 1/10 rather than the beefy
> Fraction it currently returns. To return the beast, one would
> have to intentionally invoke asExactFraction or something similar.
> 
> This might cause less surprising behavior. But I have to think more.
> 
> 
> No the goal here was to have a non null difference because we need
> to preserve inequality for other features.
> 
> Answering anything but a Float at a high computation price goes
> against primary purpose of Float (speed, efficiency)
> If that's what we want, then we shall not use Float in the first place.
> That's why I don't believe in such proposal
> 
> The minimal Fraction algorithm is an intersting challenge though.
> Not sure how to find it...

I'm thinking of a continuous fraction expansion of the exact fraction
until the partial fraction falls inside the rounding interval of the Float.

Heavy, but doable.

Not sure, however, if it always meets the stated criterion.

Re: [Pharo-dev] float & fraction equality bug

On 2017-11-09 21:49, Stephane Ducasse wrote:
> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier
>  wrote:
>> Note that this started a long time ago and comes up episodically
>> http://forum.world.st/Fraction-equality-and-Float-infinity-problem-td48323.html
>> http://forum.world.st/BUG-Equality-should-be-transitive-tc1404335.html
>> https://lists.gforge.inria.fr/pipermail/pharo-project/2009-July/010496.html
>>
>> A bit like a "marronnier" (in French, a subject that is treated periodically
>> by newspapers and magazines)
> 
> Hi nicolas except that now we could a chapter describing some of the answers 
> :)
> 

It's easy to make = behave as an equivalence if the two objects it
operates on are of the same class.

But it is well-known that it's hard when their classes are different,
short of implementing = trivially in this case.

This is to say that there's no real hope to make = an equivalence if the
wish is to make it useful in the presence of different kind of objects.

In the context of numeric computations, luckily, there is some hope when
conversions, if possible at all, are all performed consistently. But the
same conversions should then be applied for all operations, whether
comparisons or subtractions, etc., to ensure more familiar properties.
This is not currently the case in Pharo.

Raffaello

Re: [Pharo-dev] float & fraction equality bug


On 2017-11-09 19:04, Nicolas Cellier wrote:



2017-11-09 18:02 GMT+01:00 Raffaello Giulietti 
mailto:raffaello.giulie...@lifeware.ch>>:





Anyway relying upon Float equality should allways be subject to
extreme caution and examination

For example, what do you expect with plain old arithmetic in mind:

  a := 0.1.
  b := 0.3 - 0.2.
  a = b

This will lead to (a - b) reciprocal = 3.602879701896397e16
If it is in a Graphics context, I'm not sure that it's the
expected scale...



a = b evaluates to false in this example, so no wonder (a - b)
evaluates to a big number.


Writing a = b with floating point is rarely a good idea, so asking about 
the context which could justify such approach makes sense IMO.




Simple contexts, like the one which is the subject of this trail, are 
the one we should strive at because they are the ones most likely used 
in day-to-day working. Having useful properties and regularity for 
simple cases might perhaps cover 99% of the everyday usages (just a 
dishonestly biased estimate ;-) )


Complex contexts, with heavy arithmetic, are best dealt by numericists 
when Floats are involved, or with unlimited precision numbers like 
Fractions by other programmers.







But the example is not plain old arithmetic.

Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest
to 0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it
seems). Every user of Floats should be fully aware of the implicit
loss of precision that using Floats entails.


Yes, it makes perfect sense!
But precisely because you are aware that 0.1e0 is "the Float closest to 
0.1" and not exactly 1/10, you should then not be surprised that they 
are not equal.




Indeed, I'm not surprised. But then
0.1 - (1/10)
shall not evaluate to 0. If it evaluates to 0, then the numbers shall 
compare as being equal.


The surprise lies in the inconsistency between the comparison and the 
subtraction, not in the isolated operations.






I agree that following assertion hold:
     self assert: a ~= b & a isFloat & b isFloat & a isFinite & b 
isFinite ==> (a - b) isZero not




The arrow ==> is bidirectional even for finite Floats:

self assert: (a - b) isZero not & a isFloat & b isFloat & a isFinite & b 
isFinite ==> a ~= b





But (1/10) is not a Float and there is no Float that can represent it 
exactly, so you can simply not apply the rules of FloatingPoint on it.


When you write (1/10) - 0.1, you implicitely perform (1/10) asFloat - 0.1.
It is the rounding operation asFloat that made the operation inexact, so 
it's no more surprising than other floating point common sense


See above my observation about what I consider surprising.







In the case of mixed-mode Float/Fraction operations, I personally
prefer reducing the Fraction to a Float because other commercial
Smalltalk implementations do so, so there would be less pain porting
code to Pharo, perhaps attracting more Smalltalkers to Pharo.

Mixed arithmetic is problematic, and from my experience mostly happens 
in graphics in Smalltalk.


If ever I would change something according to this principle (but I'm 
not convinced it's necessary, it might lead to other strange side effects),

maybe it would be how mixed arithmetic is performed...
Something like exact difference like Martin suggested, then converting 
to nearest Float because result is inexact:

     ((1/10) - 0.1 asFraction) asFloat

This way, you would have a less surprising result in most cases.
But i could craft a fraction such that the difference underflows, and 
the assertion a ~= b ==> (a - b) isZero not would still not hold.

Is it really worth it?
Will it be adopted in other dialects?




As an alternative, the Float>>asFraction method could return the 
Fraction with the smallest denominator that would convert to the 
receiver by the Fraction>>asFloat method.


So, 0.1 asFraction would return 1/10 rather than the beefy Fraction it 
currently returns. To return the beast, one would have to intentionally 
invoke asExactFraction or something similar.


This might cause less surprising behavior. But I have to think more.






But the main point here, I repeat myself, is to be consistent and to
have as much regularity as intrinsically possible.



I think we have as much as possible already.
Non equality resolve more surprising behavior than it creates.
It makes the implementation more mathematically consistent (understand 
preserving more properties).

Tell me how you are going to sort these 3 numbers:

{1.0 . 1<<60+1/(1<<60).  1<<61+1/(1<<61)} sort.

tell me the expectation of:

{1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size.



A clearly stated rule, consistently applied and known

Re: [Pharo-dev] float & fraction equality bug


On 2017-11-09 15:55, Nicolas Cellier wrote:



2017-11-09 15:48 GMT+01:00 Tudor Girba >:


Hi,

Thanks for the answer. The example I provided was for convenience.

I still do not understand why it is wrong to expect 0.1 = (1/10) to
be true.

Doru


Because there are infinitely many different Fraction that would be 
"equal" to 0.1 then.

The first effect is that you have

a = b
a = c
b < c

You are breaking the fact that you can sort these Numbers (are they 
Magnitude anymore?)
You are breaking the fact that you can mix these Numbers as Dictionary 
keys (sometimes the dictionary would have 2 elements, sometimes 3, 
unpredictably).





Fractions are not reliable keys anyway:
(Fraction numerator: 1 denominator: 3) = (Fraction numerator: 2 
denominator: 6)

evaluates to true while
(Fraction numerator: 1 denominator: 3) hash = (Fraction numerator: 2 
denominator: 6) hash

evaluates to false

Re: [Pharo-dev] float & fraction equality bug


On 2017-11-09 15:50, Nicolas Cellier wrote:

This is out of context.
There is no such thing as Fraction type covered by IEEE 754 standard.



Yes, I agree. But we should still strive to model arithmetic embracing 
the principle of least surprise. That's why in every arithmetic system 
I'm aware of (with the exception of very old CPUs dating back several 
decades), for finite x, y the

x = y if and only if x - y = 0
property holds.

Let's put it in another perspective: what's the usefulness of having
x = y
evaluate to false just to discover that
x - y
evaluates to 0, or the other way round?







Anyway relying upon Float equality should allways be subject to extreme 
caution and examination


For example, what do you expect with plain old arithmetic in mind:

     a := 0.1.
     b := 0.3 - 0.2.
     a = b

This will lead to (a - b) reciprocal = 3.602879701896397e16
If it is in a Graphics context, I'm not sure that it's the expected scale...




a = b evaluates to false in this example, so no wonder (a - b) evaluates 
to a big number.


But the example is not plain old arithmetic.

Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest to 
0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it seems). 
Every user of Floats should be fully aware of the implicit loss of 
precision that using Floats entails.


So, using Floats to represent decimal numbers is the real culprit in 
this example, not the underlying Float arithmetic, which is very well 
defined from a mathematical point of view. In other words, using Floats 
to emulate decimal arithmetic will frustrate anybody because Floats work 
with limited precision binary arithmetic. Users wanting to engage in 
decimal arithmetic should simply not use Floats. (That's the reason for 
the addition of limited precision decimal arithmetic and numbers in the 
IEEE 754-2008 standard.)


That said, this does not mean we should give up useful properties like 
the one discussed above. Since we *can* ensure this property, we also 
should, in the spirit of the principle of least surprise.


What's problematic in Pharo is that comparison works in one way while 
subtraction works in another way but, mathematically, these operations 
are essentially the same. So let's be consistent.


In the case of mixed-mode Float/Fraction operations, I personally prefer 
reducing the Fraction to a Float because other commercial Smalltalk 
implementations do so, so there would be less pain porting code to 
Pharo, perhaps attracting more Smalltalkers to Pharo.


But the main point here, I repeat myself, is to be consistent and to 
have as much regularity as intrinsically possible.

Re: [Pharo-dev] float & fraction equality bug

According to IEEE 754, the base of Pharo Float, *finite* values shall 
behave like old plain arithmetic.





On 2017-11-09 15:36, Nicolas Cellier wrote:

Nope, not a bug.

If you use Float, then you have to know that (x -y) isZero and (x = y) 
are two different things.

Example; Float infinity

In your case you want to protect against (x-y) isZero, so just do that.

2017-11-09 15:15 GMT+01:00 Tudor Girba >:


Hi,

I just stumbled across this bug related to the equality between
fraction and float:

https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-Pharo



In essence, the problem can be seen that by doing this, you get a
ZeroDivide:
x := 0.1.
y := (1/10).
x = y ifFalse: [ 1 / (x - y) ]

The issue seems to come from the Float being turned to a Fraction,
rather than the Fraction being turned into a Float:

Fraction(Number)>>adaptToFloat: rcvr andCompare: selector
"If I am involved in comparison with a Float, convert rcvr to a
Fraction. This way, no bit is lost and comparison is exact."

rcvr isFinite
ifFalse: [
selector == #= ifTrue: [^false].
selector == #~= ifTrue: [^true].
rcvr isNaN ifTrue: [^ false].
(selector = #< or: [selector = #'<='])
ifTrue: [^ rcvr positive not].
(selector = #> or: [selector = #'>='])
ifTrue: [^ rcvr positive].
^self error: 'unknow comparison selector'].

^ *rcvr asTrueFraction perform: selector with: self*

Even if the comment says that the comparison is exact, to me this is
a bug because it seems to fail doing that. What do you think?

Cheers,
Doru


--
www.tudorgirba.com 
www.feenk.com 

"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win


Hi Nicolas,

I understand.



And I can confirm that the Squeak 64 bit/win VM SqueakSSL.dll works when 
copied in the Pharo 64 bit/win folder.


Thanks for the patience
Raffaello



On 2017-11-06 17:21, Nicolas Cellier wrote:
No matter which step fails, the build is considered failed if return 
code differs from 0...


2017-11-06 15:23 GMT+01:00 Raffaello Giulietti 
mailto:raffaello.giulie...@lifeware.ch>>:


Hi Nicolas,

seems that only the upload to the Pharo repo fails, not the building
by itself.

But the cog_win64x64_pharo.stack.spur_201711061254.zip is not even
on the bintray repo. I would expect it at least there. Is that
right? Just wondering...

Of course, I'll try to grab the SqueakSSL.dll from the squeak 64
bit/win vm.




On 2017-11-06 15:05, Nicolas Cellier wrote:

Unfortunately, the VM is corectly built, but the script fails at
deploy stage...

https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/gx20b215gls5jq7w

<https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/gx20b215gls5jq7w>

Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to
pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win
<http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win>
<http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win
<http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win>>
Warning: Permanently added the RSA host key for IP address
'193.51.193.142' to the list of known hosts.
Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to
pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip

<http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip>

<http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip

<http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip>>
scp: /appli/files.pharo.org/vm/pharo-spur64/win/latest.zip
<http://files.pharo.org/vm/pharo-spur64/win/latest.zip>
<http://files.pharo.org/vm/pharo-spur64/win/latest.zip
<http://files.pharo.org/vm/pharo-spur64/win/latest.zip>>:
Permission denied
Command exited with code 1

At this stage, there's not much i can do.
You'll have to ask to Pharo team to correct this problem.

In the interim, I suggest you download the Squeak VM for Win64
and pick SqueakSSL.dll there...

2017-11-06 11:34 GMT+01:00 Raffaello Giulietti
mailto:raffaello.giulie...@lifeware.ch>
<mailto:raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>>>:

     Thanks Nicolas!



     On 2017-11-06 11:30, Nicolas Cellier wrote:

         Oh yes, you're right,
         the SqueakSLL could have been built but was not built
in pharo...
         I just changed

https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/pharo.cog.spur/plugins.ext

<https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/pharo.cog.spur/plugins.ext>

<https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/pharo.cog.spur/plugins.ext


<https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/pharo.cog.spur/plugins.ext>>
         this should trigger another automated build and if all
    goes well
         you will have a new bintray artefact to test.

         2017-11-06 10:21 GMT+01:00 Raffaello Giulietti
         mailto:raffaello.giulie...@lifeware.ch>
         <mailto:raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>>
         <mailto:raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>

         <mailto:raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>>>>:


              Hi Nicolas,

              I tried both the vm found at the location you
mention (dated
              2017-10-22):


https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip

<https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip>

<https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip


<https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip>>

<https://bintray.com/opensma

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win


Hi Nicolas,

seems that only the upload to the Pharo repo fails, not the building by 
itself.


But the cog_win64x64_pharo.stack.spur_201711061254.zip is not even on 
the bintray repo. I would expect it at least there. Is that right? Just 
wondering...


Of course, I'll try to grab the SqueakSSL.dll from the squeak 64 bit/win vm.




On 2017-11-06 15:05, Nicolas Cellier wrote:
Unfortunately, the VM is corectly built, but the script fails at deploy 
stage...

https://ci.appveyor.com/project/OpenSmalltalk/vm/branch/Cog/job/gx20b215gls5jq7w

Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to 
pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win 
<http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win>
Warning: Permanently added the RSA host key for IP address 
'193.51.193.142' to the list of known hosts.
Uploading ./pharo-win-x86_64-201711061254-f819c8f.zip to 
pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip 
<http://pharo.files.org//appli/files.pharo.org/vm/pharo-spur64/win/latest.zip>
scp: /appli/files.pharo.org/vm/pharo-spur64/win/latest.zip 
<http://files.pharo.org/vm/pharo-spur64/win/latest.zip>: Permission denied

Command exited with code 1

At this stage, there's not much i can do.
You'll have to ask to Pharo team to correct this problem.

In the interim, I suggest you download the Squeak VM for Win64 and pick 
SqueakSSL.dll there...


2017-11-06 11:34 GMT+01:00 Raffaello Giulietti 
mailto:raffaello.giulie...@lifeware.ch>>:


Thanks Nicolas!



On 2017-11-06 11:30, Nicolas Cellier wrote:

Oh yes, you're right,
the SqueakSLL could have been built but was not built in pharo...
I just changed

https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/pharo.cog.spur/plugins.ext

<https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/pharo.cog.spur/plugins.ext>
this should trigger another automated build and if all goes well
you will have a new bintray artefact to test.

2017-11-06 10:21 GMT+01:00 Raffaello Giulietti
mailto:raffaello.giulie...@lifeware.ch>
<mailto:raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>>>:


     Hi Nicolas,

     I tried both the vm found at the location you mention (dated
     2017-10-22):


https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip

<https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip>

<https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip


<https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip>>

     and the "official" latest vm on the Pharo site (dated
2017-11-01)


http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e14fbab.zip

<http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e14fbab.zip>

<http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e14fbab.zip


<http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e14fbab.zip>>



     Neither of them contains the SqueakSSL.dll and, in fact, in
both
     cases I get an exception when using Gofer to download Roassal2,
     using the latest 60519 image:

     Gofer it
          smalltalkhubUser: 'ObjectProfile' project: 'Roassal2';
          configurationOf: 'Roassal2';
          loadDevelopment

     This works on Pharo 32 bit/Win, where SquekSSL is present.








     On 2017-11-04 23:31, Nicolas Cellier wrote:

         Note that win64 SSL works at least since

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510f2edf7465e857c645be0e4

<https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510f2edf7465e857c645be0e4>

<https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510f2edf7465e857c645be0e4


<https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510f2edf7465e857c645be0e4>>
         and

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecaea5236b3d3e3c0d303c6eb4

<https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecaea5236b3d3e3c0d303c6eb4>

<https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecaea5236b3d3e3c0d303c6eb4


<https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win


Thanks Nicolas!



On 2017-11-06 11:30, Nicolas Cellier wrote:

Oh yes, you're right,
the SqueakSLL could have been built but was not built in pharo...
I just changed 
https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/pharo.cog.spur/plugins.ext
this should trigger another automated build and if all goes well you 
will have a new bintray artefact to test.


2017-11-06 10:21 GMT+01:00 Raffaello Giulietti 
mailto:raffaello.giulie...@lifeware.ch>>:


Hi Nicolas,

I tried both the vm found at the location you mention (dated
2017-10-22):


https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip

<https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip>

and the "official" latest vm on the Pharo site (dated 2017-11-01)


http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e14fbab.zip

<http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e14fbab.zip>



Neither of them contains the SqueakSSL.dll and, in fact, in both
cases I get an exception when using Gofer to download Roassal2,
using the latest 60519 image:

Gofer it
     smalltalkhubUser: 'ObjectProfile' project: 'Roassal2';
     configurationOf: 'Roassal2';
     loadDevelopment

This works on Pharo 32 bit/Win, where SquekSSL is present.








On 2017-11-04 23:31, Nicolas Cellier wrote:

Note that win64 SSL works at least since

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510f2edf7465e857c645be0e4

<https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510f2edf7465e857c645be0e4>
and

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecaea5236b3d3e3c0d303c6eb4

<https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecaea5236b3d3e3c0d303c6eb4>

Maybe it's a bit too recent to be found in official Pharo
distribution, but if you can live with bleeding edge, pick a
more recent VM here:
https://bintray.com/opensmalltalk/vm/cog/201710221351#files
<https://bintray.com/opensmalltalk/vm/cog/201710221351#files>
(or maybe you can find one from the Pharo site?)


2017-11-04 22:21 GMT+01:00 henry mailto:he...@callistohouse.club
<mailto:he...@callistohouse.club>>>:

     This is the advantage of in-image SSL solution, found in the
     Cryptography repository:

http://www.squeaksource.com/Cryptography.html
<http://www.squeaksource.com/Cryptography.html>
     <http://www.squeaksource.com/Cryptography.html
<http://www.squeaksource.com/Cryptography.html>>

     Sent from ProtonMail Mobile


     On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti
     mailto:raffaello.giulie...@lifeware.ch>
     <mailto:raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>>> wrote:

     Hi, the SqueakSSL dll is not included in the Pharo
64bit/Win vm
     distribution. I guess this has to do with problems in
building it.
     Anybody knows where the difficulties lie? Greetings
Raffaello

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win


Hi Nicolas,

I tried both the vm found at the location you mention (dated 2017-10-22):


https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_pharo.cog.spur_201710221351.zip

and the "official" latest vm on the Pharo site (dated 2017-11-01)


http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e14fbab.zip



Neither of them contains the SqueakSSL.dll and, in fact, in both cases I 
get an exception when using Gofer to download Roassal2, using the latest 
60519 image:


Gofer it
smalltalkhubUser: 'ObjectProfile' project: 'Roassal2';
configurationOf: 'Roassal2';
loadDevelopment

This works on Pharo 32 bit/Win, where SquekSSL is present.








On 2017-11-04 23:31, Nicolas Cellier wrote:

Note that win64 SSL works at least since
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510f2edf7465e857c645be0e4
and
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecaea5236b3d3e3c0d303c6eb4

Maybe it's a bit too recent to be found in official Pharo distribution, 
but if you can live with bleeding edge, pick a more recent VM here:
https://bintray.com/opensmalltalk/vm/cog/201710221351#files (or maybe 
you can find one from the Pharo site?)



2017-11-04 22:21 GMT+01:00 henry <mailto:he...@callistohouse.club>>:


This is the advantage of in-image SSL solution, found in the
Cryptography repository:

http://www.squeaksource.com/Cryptography.html
<http://www.squeaksource.com/Cryptography.html>

Sent from ProtonMail Mobile


On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti
mailto:raffaello.giulie...@lifeware.ch>> wrote:

Hi, the SqueakSSL dll is not included in the Pharo 64bit/Win vm
distribution. I guess this has to do with problems in building it.
Anybody knows where the difficulties lie? Greetings Raffaello

[Pharo-dev] SqueakSSL on Pharo 64bit/Win

2017-11-03 Thread Raffaello Giulietti


Hi,

the SqueakSSL dll is not included in the Pharo 64bit/Win vm distribution.
I guess this has to do with problems in building it.
Anybody knows where the difficulties lie?

Greetings
Raffaello

[Pharo-dev] VM specific mailing list

2017-10-17 Thread Raffaello Giulietti


Hi,

is there a specific mailing list to discuss about Pharo's VM?

Greetings
Raffaello

[Pharo-dev] Error in ByteArray>>booleanAt:

2017-06-22 Thread Raffaello Giulietti


Hi,

the current (Pharo 6) code reads

^(self integerAt: byteOffset size: 1 signed: false) == true

so it always returns false, as no integer is identical to true.


Instead, it should read

^(self integerAt: byteOffset size: 1 signed: false) ~= 0

implementing the usual convention that 0 maps to false and every other 
value maps to true.


Greetings
Raffaello

Re: [Pharo-dev] Smalltalk Internet Browser

2017-05-05 Thread raffaello . giulietti

On 05/05/17 12:25, Craig Latta wrote:
> 
>  Raffaello writes:
> 
>> If I understand the proposal correctly, something similar was tried in
>> project Lively Kernel (https://www.lively-kernel.org/), which is dead
>> since long...
> 
>  That project is alive, actually.
> 

The last news and copyright notices are from 2012, the last release is
from February 2014, the last mailing list entry is from August 2016 and
its gzipped volume in the last year is less than 5 KB.

Would anybody honestly call such a project "alive"?

Re: [Pharo-dev] Smalltalk Internet Browser

2017-05-04 Thread raffaello . giulietti

If I understand the proposal correctly, something similar was tried in
project Lively Kernel (https://www.lively-kernel.org/), which is dead
since long and was marginally relevant perhaps only in the academic
field and not at all in the real world.

Personally, I think there are better ways to spend the scarce but
otherwise good human resources involved in the Smalltalk world: but
anyway, good luck.

Greetings
Raffaello

On 04/05/17 17:55, askoh wrote:
> Thanks everyone for digging out the various possibilities. It is heartening
> to know the community is healthy and engaging.
> 
> Let me summarize the possibilities:
> 1) Recompile Smalltalk VM from C to WebAssembly to run inside a browser at
> near native speed. This means a complete Smalltalk IDE inside a browser with
> full access to the browser innards.
> 2) Embed Chromium or ChromeHeadless or WebKit inside the Smalltalk IDE.
> Browser access is through the exposed APIs.
> 3) Enhance Scamper, a basic browser written in Smalltalk, to include more
> and more of the capabilities of Chrome say.
> 
> All the best,
> Aik-Siong Koh
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Smalltalk-Internet-Browser-tp4944879p4945606.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library


On 2017-05-03 18:05, Denis Kudriashov wrote:


2017-05-03 16:28 GMT+02:00 Raffaello Giulietti 
mailto:raffaello.giulie...@lifeware.ch>>:


Sorry, Phil, this is (currently) not open source software for many
reasons. Depending on how Pharo moves in the future, however, we
might consider opening it.


So you are not using JNIPort? 
http://forum.world.st/ANN-JNIPort-for-Pharo-3-0-alpha-td4750750.html.




No, we have our own solution since more than 10 years.
JNIPort seems old and it seems Pharo specific.
Besides, in addition to Pharo we have to target and to maintain other 
two quite different environments. We want a similar architecture on all 
of them.

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

Sorry, Phil, this is (currently) not open source software for many
reasons. Depending on how Pharo moves in the future, however, we might
consider opening it.

On 2017-05-03 16:09, p...@highoctane.be wrote:

How could I load that JVM bridge?

I am having a use case or two for that and was thinking that this was
not working with new Pharos.

TIA
Phil

On Wed, May 3, 2017 at 2:32 PM, Raffaello Giulietti
wrote:

Problem solved.

The cause was a mismatch between a 0-based index and a 1-based index on
copying arrays between Smalltalk and C.

Rather confusingly, for some reason, FFI indices are 1-based even for C
arrays, so that calling ExternalAddress>>byteAt:put:, for example, requires
the index to be unnaturally 1-based.

While I put a lot of care at this issue, a specific spot in the code was
erroneous, leading to an improperly terminated C-style string which, in
turn, caused the indirect crash of Pharo.

My fault, however, neither Pharo's nor the JVM's.

Thanks to all involved in replies.

Greetings
Raffaello

On 2017-05-03 13:52, Ben Coman wrote:

On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti
mailto:raffaello.giulie...@lifeware.ch>>
wrote:

Unfortunately, as I just discovered, older versions of Pharo do not
support UFFI. I don't have the time (nor a real interest) in
backporting the code to an older pre-Spur VM which has probably
reached its EOL just for the sake of experimentation. It would
probably take hours to understand the older FFI model and to adapt
the code for no real advantage.

The current Pharo VM seems to support only the --memory option: I
tried with 1 and 2 GiB, nothing changes in the misbehavior.

I also tried the two heap-related JVM options in isolation,
unsuccessfully. Just for information, the current values for the
options are -Xms16m and -Xmx512m, meaning that the JVM heap should
start with 16 MiB and grow to a maximum size of 512 MiB, both of
which are rather modest values even for a 32 bit process. Besides,
they work in VisualWorks (32 bit).

What about tiny memory allocation like --memory 100m and -Xmx 100m ?

Can you share some code that causes the crash?

cheers -ben

The StackOverflow page indicated below is from year 2010, during the
age of Java 6. The JVM has undergone major changes since then,
including memory management, so I'm not sure the discussion there is
relevant for Java 8, the release we are targeting as of today. But
even if it were, I still cannot understand the crash in Pharo.

On 2017-05-03 06:36, Ben Coman wrote:

On Wed, May 3, 2017 at 12:30 AM, Denis Kudriashov
mailto:dionisi...@gmail.com>
<mailto:dionisi...@gmail.com <mailto:dionisi...@gmail.com>>>
wrote:

Could you check how it works with Pharo5 which was based on
prespur
CogVM?

Note, Pharo 5 Release was a Spur VM.
Try using...
http://files.pharo.org/get-files/50-preSpur/
<http://files.pharo.org/get-files/50-preSpur/>
http://files.pharo.org/image/50-preSpur/50495.zip
<http://files.pharo.org/image/50-preSpur/50495.zip>

or even Pharo 4.

cheers -ben

2017-05-02 16:36 GMT+02:00 Raffaello Giulietti
mailto:raffaello.giulie...@lifeware.ch>
<mailto:raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>>>:

Hello,

I'm on Pharo 6 (32 bit)/Windows 10 (64 bit).

I'm trying to load and use the (32 bit) JVM DLL into a
running
Pharo image via the UFFI.

Everything works correctly, including JVM method
invocations,
except when trying to set the minimum and maximum JVM
heap size
by passing the -Xms and -Xmx options upon JVM
creation. With these options, Pharo simply crashes
without
leaving any trace.

Can you isolate whether the problem is either one of those, or
it happens with both, and if there is some cutoff where it
works? Also, perhaps try limiting heap being used by Pharo
--memory [mk]use fixed heap size (added to
image size)
--mmap [mk] limit dynamic heap size (default:
1024m) [out 2G on 32-bit)
--maxoldspace [mk]set max size of old space
memory to bytes
(disclaimer, I'm not too knowledgeable on these, just
pulled them from --help)

Also consider that heap needs to be contiguous...

**http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-32bit-vs-64bit

<http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-si

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library


Hi Ben,


On 2017-05-03 14:56, Ben Coman wrote:

Thanks for the follow up.  Glad to hear its nothing intrinsic to Pharo.

btw, Is there somewhere in the documentation or class/method comments 
that you believe this N-base situation should be spelled out better?





Well, I wouldn't call the parameter of ExternalAddress>>byteAt:... 
methods a "byteOffset", as offset invariably indicates a *difference* 
between indices or addresses. Thus, I would for example expect an offset 
of 0 to refer to the first byte, whether its index is 0 or 1.


This is in contrast with the Smalltalk convention that At: 
selectors with numerical arguments usually mean a 1-based *index*.




BTW, just for information, what is your role in the development of Pharo?


Greetings
Raffaello

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

Problem solved.

The cause was a mismatch between a 0-based index and a 1-based index on
copying arrays between Smalltalk and C.

Rather confusingly, for some reason, FFI indices are 1-based even for C
arrays, so that calling ExternalAddress>>byteAt:put:, for example,
requires the index to be unnaturally 1-based.

While I put a lot of care at this issue, a specific spot in the code was
erroneous, leading to an improperly terminated C-style string which, in
turn, caused the indirect crash of Pharo.

My fault, however, neither Pharo's nor the JVM's.

Thanks to all involved in replies.

Greetings
Raffaello

On 2017-05-03 13:52, Ben Coman wrote:

On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti
<mailto:raffaello.giulie...@lifeware.ch>> wrote:

The current Pharo VM seems to support only the --memory option: I
tried with 1 and 2 GiB, nothing changes in the misbehavior.

What about tiny memory allocation like --memory 100m and -Xmx 100m ?

Can you share some code that causes the crash?

cheers -ben

On 2017-05-03 06:36, Ben Coman wrote:

On Wed, May 3, 2017 at 12:30 AM, Denis Kudriashov
mailto:dionisi...@gmail.com>
<mailto:dionisi...@gmail.com <mailto:dionisi...@gmail.com>>> wrote:

Could you check how it works with Pharo5 which was based on
prespur
CogVM?

or even Pharo 4.

cheers -ben

2017-05-02 16:36 GMT+02:00 Raffaello Giulietti
mailto:raffaello.giulie...@lifeware.ch>
<mailto:raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>>>:

Hello,

I'm on Pharo 6 (32 bit)/Windows 10 (64 bit).

I'm trying to load and use the (32 bit) JVM DLL into a
running
Pharo image via the UFFI.

Also consider that heap needs to be contiguous...

**http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-32bit-vs-64bit

<http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-32bit-vs-64bit>
cheers -ben

Apparently, memory management requests from the JVM
interfere
with Pharo's own memory management.

Please note that we successfully use the same mechanism
for both
VisualWorks (32 bit)/Windows 10 (64 bit) and Gemstone 64
bit/Linux, so it seems it has to do with a Pharo
limitation somehow.

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

No, that does not work, as I reported:

On 2017-05-03 10:33, Raffaello Giulietti wrote:
> The current Pharo VM seems to support only the --memory option: I tried
> with 1 and 2 GiB, nothing changes in the misbehavior.

Further, Pharo crashes even when only *starting* with a JVM heap size of 
16 MiB, a ridiculously small heap, regardless of the Pharo --memory 
option and the JVM max heap option.

On 2017-05-03 10:55, Esteban Lorenzano wrote:

mmm… you can try assigning memory to pharo itself.

--memory 1000m

(for example)

but it may happens that pharo + jvm exceeds the 2g max of a 32bits vm?

Esteban

On 3 May 2017, at 10:52, Raffaello Giulietti  
wrote:

OK, thanks, here it is:

CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 
Apr 18 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: 
ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017
VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: 
Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $

Seems what PharoConsole outputs, too.

On 2017-05-03 10:49, Esteban Lorenzano wrote:

execute
Smalltalk vm version
in playground

On 3 May 2017, at 10:47, Raffaello Giulietti  
wrote:

Hi,

how do I discover?

I tried with Pharo.exe --version but this shows nothing.

Conversely, with PharoConsole here is what I obtain.

C:\pharo6\PharoConsole.exe --version

Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM]
CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 
Apr 18 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: 
ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017
VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: 
Tue Apr 18 12:25:44 2017 -0700 $
Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $

On 2017-05-03 10:36, Esteban Lorenzano wrote:

Hi,
which vm version are you using?
Esteban

On 2 May 2017, at 16:36, Raffaello Giulietti  
wrote:

Hello,

I'm on Pharo 6 (32 bit)/Windows 10 (64 bit).

I'm trying to load and use the (32 bit) JVM DLL into a running Pharo image via 
the UFFI.

Everything works correctly, including JVM method invocations, except when trying to set the 
minimum and maximum JVM heap size by passing the -Xms and -Xmx 
options upon JVM creation. With these options, Pharo simply crashes without leaving any 
trace.

Apparently, memory management requests from the JVM interfere with Pharo's own 
memory management.

Please note that we successfully use the same mechanism for both VisualWorks 
(32 bit)/Windows 10 (64 bit) and Gemstone 64 bit/Linux, so it seems it has to 
do with a Pharo limitation somehow.

Further, I couldn't find any documentation on how to increase Pharo's working 
set.

So the questions are:
* What is the most probable cause of the crash described above?
* Where is there more doc about Pharo's memory configuration settings?

Greetings
Raffaello

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library


OK, thanks, here it is:


CoInterpreter VMMaker.oscog-eem.2197 uuid: 
ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: 
ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017
VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ 
Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $



Seems what PharoConsole outputs, too.




On 2017-05-03 10:49, Esteban Lorenzano wrote:

execute

Smalltalk vm version

in playground


On 3 May 2017, at 10:47, Raffaello Giulietti  
wrote:

Hi,

how do I discover?

I tried with Pharo.exe --version but this shows nothing.

Conversely, with PharoConsole here is what I obtain.


C:\pharo6\PharoConsole.exe --version

Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM]
CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 
Apr 18 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: 
ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017
VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: 
Tue Apr 18 12:25:44 2017 -0700 $
Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $






On 2017-05-03 10:36, Esteban Lorenzano wrote:

Hi,
which vm version are you using?
Esteban

On 2 May 2017, at 16:36, Raffaello Giulietti  
wrote:

Hello,

I'm on Pharo 6 (32 bit)/Windows 10 (64 bit).

I'm trying to load and use the (32 bit) JVM DLL into a running Pharo image via 
the UFFI.

Everything works correctly, including JVM method invocations, except when trying to set the 
minimum and maximum JVM heap size by passing the -Xms and -Xmx 
options upon JVM creation. With these options, Pharo simply crashes without leaving any 
trace.

Apparently, memory management requests from the JVM interfere with Pharo's own 
memory management.

Please note that we successfully use the same mechanism for both VisualWorks 
(32 bit)/Windows 10 (64 bit) and Gemstone 64 bit/Linux, so it seems it has to 
do with a Pharo limitation somehow.

Further, I couldn't find any documentation on how to increase Pharo's working 
set.

So the questions are:
* What is the most probable cause of the crash described above?
* Where is there more doc about Pharo's memory configuration settings?

Greetings
Raffaello

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library


Hi,

how do I discover?

I tried with Pharo.exe --version but this shows nothing.

Conversely, with PharoConsole here is what I obtain.

>C:\pharo6\PharoConsole.exe --version
Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM]
CoInterpreter VMMaker.oscog-eem.2197 uuid: 
ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: 
ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017
VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ 
Date: Tue Apr 18 12:25:44 2017 -0700 $
Plugins: 201704181925 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $







On 2017-05-03 10:36, Esteban Lorenzano wrote:

Hi,

which vm version are you using?

Esteban


On 2 May 2017, at 16:36, Raffaello Giulietti  
wrote:

Hello,

I'm on Pharo 6 (32 bit)/Windows 10 (64 bit).

I'm trying to load and use the (32 bit) JVM DLL into a running Pharo image via 
the UFFI.

Everything works correctly, including JVM method invocations, except when trying to set the 
minimum and maximum JVM heap size by passing the -Xms and -Xmx 
options upon JVM creation. With these options, Pharo simply crashes without leaving any 
trace.

Apparently, memory management requests from the JVM interfere with Pharo's own 
memory management.

Please note that we successfully use the same mechanism for both VisualWorks 
(32 bit)/Windows 10 (64 bit) and Gemstone 64 bit/Linux, so it seems it has to 
do with a Pharo limitation somehow.

Further, I couldn't find any documentation on how to increase Pharo's working 
set.

So the questions are:
* What is the most probable cause of the crash described above?
* Where is there more doc about Pharo's memory configuration settings?

Greetings
Raffaello

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library