Re: [Pharo-dev] roundTo: strange behavior

[Martin McClure]

On 11/05/2016 06:17 AM, werner kassens wrote:

Hi,
fwiw when i redid that #testIfCompletelyBroken i noticed a sort of bug 
in that new #round: - well, i think its a feature -, but i should 
probably mention it nevertheless:

1.15 round:1. "1.1""down"
1.25 round:1. "1.3""up"
1.35 round:1. "1.4""up"
1.45 round:1. "1.4""down"
1.55 round:1. "1.6""up"
1.65 round:1. "1.6""down"
btw the same happens with #printShowingDecimalPlaces: (which is 
unchanged, happens eg also in 4.0).


if one wants to change this to the normal behaviour, i'd guess one 
could do it perhaps by using #asMinimalDecimalFraction instead of 
#asFraction in #round:



This is, in part, an example of it being difficult to predict, at a 
glance, what #round: should do, without an understanding of the 
strengths and limitations of binary floating point numbers.


Remember that Floats are not usually exact representations of nice 
decimal fractions. So most of these numbers are not *exactly* halfway 
between their possible roundings.


1.15 < (115/100) "true"
1.25 = (125/100) "true"
1.35 > (135/100) "true"
1.45 < (145/100) "true"
1.55 > (155/100) "true"
1.65 < (165/100) "true"

In every case except 1.25, the answer is the correct rounding, that, is 
the one that is closer. For 1.25, the number *is* exactly halfway 
between two roundings. For round-to-even (which I recommend) the answer 
should be 1.2, so it gets that one "wrong".


Regards,

-Martin

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

[Eliot Miranda]

Hi Petr,

> On Nov 4, 2016, at 3:56 PM, Petr Fischer  wrote:
> 
> Also on FreeBSD, there is no security/limits config, so on FreeBSD, I am not 
> able to run heartbeat VM as normal user at all :(
> 
> Ins't there any other solution? Why "realtime" threads?

There's nothing special about the heartbeat thread apart from needing to have a 
higher priority than the VM thread.

> Isn't possible to run "heartbeat" thread with normal priority and all other 
> threads with lower priorities to provide the same behaviour?

This should work provided one can create a thread of lower priority, and 
providing having the VM thread being lower priority doesn't impact VM 
performance when other applications are running.

IIRC it wasn't possible on the linux pthreads implementation in the 2.4.x 
kernel dats when I first got Cog working in linux to have a thread at higher or 
lower priority; there was only one priority available to user programs.  Have 
you tried to create a couple of threads with different priorities on FreeBSD?

> How to deploy application based on Pharo to the normal (UNIX) users, if 
> security reconfiguration is needed?
> 
> pf
> 
> P.S. VM wihout heartbeat is crashing on FreeBSD randomly with error "stack 
> page bytes 4096 available headroom 2788 minimum unused headroom 3020" :(
> 
> 
>> BTW, the threaded version requires to be run as super user because it
>> tries to do a pthread_setschedparam(). I tried to fiddle with
>> /etc/security/limits.conf... but it's not something fancy to do...
>> 
>> Best regards,
>> 
>> Casimiro Barreto
>> 
>> Em 03-11-2016 13:53, Thierry Goubier escreveu:
>>> Hi Esteban,
>>> 
>>> Another question about Pharo 64 bits.
>>> 
>>> Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides
>>> them with the same version numbers, more or less.
>>> (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm,
>>> SDL and ssh are the exact same versions).
>>> 
>>> Collectively, those three libs are ~ 5M.
>>> 
>>> Thierry
>>> 
>>> 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano >> >:
>>> 
>>>VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>>>
>>>Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>>>
>>> 
>>>this is still not official (that’s why is not in official place)
>>>so there are a couple of known problems: 
>>> 
>>>- version format is different, and that breaks some things in
>>>image that depends on it to know what happens
>>>- command line is different and probably you’ll need to play a bit
>>>with options (one or two dashes). 
>>>- UFFI has some failing tests (but most of it works).
>>> 
>>>I would appreciate some help to report and/or fix the emerging
>>>problems. 
>>> 
>>>cheers, 
>>>Esteban
>>> 
On 28 Oct 2016, at 10:39, Thierry Goubier
> wrote:
 
Hi all,
 
anybody knows how to get (and test) the 64bits version of the
Pharo vm and image?
 
Thanks,
 
Thierry
>>> 
>>> 
>> 
>> 
>> -- 
>> The information contained in this message is confidential and intended
>> to the recipients specified in the headers. If you received this message
>> by error, notify the sender immediately. The unauthorized use,
>> disclosure, copy or alteration of this message are strictly forbidden
>> and subjected to civil and criminal sanctions.
>> 
>> ==
>> 
>> This email may be signed using PGP key *ID: 0x4134A417*
> 
> 
> 
> 

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

[Paul DeBruicker]

I never got around to it resurrecting it (I don't have the skill, yet (ever?)
;) ) but there is the BerkeleyDbPlugin which should be portable to LMDB
here:

https://github.com/pdebruic/BerkeleyDBPlugin






Jan van de Sandt wrote
> Hi,
> 
> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
> looking good. I'm testing a small library of mine [1] to interface with
> LMDB [1], a memory mapped key-value database. Almost all tests are green.
> This is great progress!
> 
> I only ran into one issue, a PrimitiveFailed error with #basicIdentityHash
> in the SmallFloat64 class.
> 
> Cheers,
> Jan.
> 
> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
> [2] https://symas.com/products/lightning-memory-mapped-database/
> 
> 
> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano 

> estebanlm@

> 
> wrote:
> 
>> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>>
>> this is still not official (that’s why is not in official place) so there
>> are a couple of known problems:
>>
>> - version format is different, and that breaks some things in image that
>> depends on it to know what happens
>> - command line is different and probably you’ll need to play a bit with
>> options (one or two dashes).
>> - UFFI has some failing tests (but most of it works).
>>
>> I would appreciate some help to report and/or fix the emerging problems.
>>
>> cheers,
>> Esteban
>>
>> On 28 Oct 2016, at 10:39, Thierry Goubier 

> thierry.goubier@

> 
>> wrote:
>>
>> Hi all,
>>
>> anybody knows how to get (and test) the 64bits version of the Pharo vm
>> and
>> image?
>>
>> Thanks,
>>
>> Thierry
>>
>>
>>





--
View this message in context: 
http://forum.world.st/Instructions-for-Pharo-6-64bits-tp4920476p4921798.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] why sparta depends on Taskit?

[stepharo]

why sparta depends on Taskit?


Since I cannot load it I cannot try to understand. I find strange that a 
graphical canvas depends on a concurrent task management system.


I tried to follow the instruction given by glenn and it failed. So so 
far I could not see any recent versions of Bloc.


I do not understand why the image produced by the jenkins job crashes my 
vm.



Stef


wget -O - http://get.pharo.org/60+vm | bash
./pharo Pharo.image config 
http://www.smalltalkhub.com/mc/Pharo/Bloc/main ConfigurationOfBloc 
--install=development



just failed yesterday for me.

Re: [Pharo-dev] Newbie(ish) Question on SVG with Athens / Roassal / Spec

[stepharo]

Hi Graham




Hi

I am contemplating moving an old Pharo app (1.4 vintage) which used 
Morphic heavily into the new Pharo world (Pharo 5).
One of the options is to move a proprietary vector graphic 
implementation which draws symbols to SVG.


Looking for examples / documentation on the use of SVG (external 
files, not image defined paths) has been very frustrating.
All examples I have found have been old and none of the file based / 
load ones work.


Can anyone please point me to good documentation / examples?
I want to understand how one can use:
SVG with Athens

I think that there is an example around for SVG in Athens.
There some limits due to cairo because certain arcs are not supported by 
cairo.

SVG with Spec
Spec should be extended to offer a container displaying Athens canvas I 
imagine.



SVG loaded from a file with Roassal

I imagine that roassal does not do anything special besides using Athens.




Thanks in advance.

Graham

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

[Thierry Goubier]

Le 05/11/2016 à 15:10, Esteban Lorenzano a écrit :



On 5 Nov 2016, at 12:27, Thierry Goubier  wrote:

Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :

Hi,

With the latest 64bits VM (201611042126) and image (60282) UFFI is also
looking good. I'm testing a small library of mine [1] to interface with
LMDB [1], a memory mapped key-value database. Almost all tests are
green. This is great progress!


Hi Jan,

did you have to change your UFFI definitions to match the 64bits version of 
your lib?


no.
but structures do change (because of sizes, of course).
I’m thinking a way to define a generic representation (keeping offsets 
somewhere instead hardcoding it), but for now they have to be redefined for 
each platform.


I'd really like, as I told Eliot a long time ago, to have fine control 
on this sort of choices.


Mostly because in low-level libs and performance sensitive code, a 32 
bits and a 64bits lib may have a very different API (in terms of 
structure size, padding and alignment) (and even between versions of, 
say, a 64bits lib). A C developper is allowed to handle and generate 
differences by using #ifdefs and __attributes__ and typeof/alignof, 
including things like that :


typedef struct {
  long long __max_align_ll __attribute__((__aligned__(__alignof__(long 
long;
  long double __max_align_ld 
__attribute__((__aligned__(__alignof__(long double;

} max_align_t;

Because a Pharo image (and a package) may be executed on a large set of 
target platforms / versions, then it seems necessary to me to have the 
ability to write ourself the code that adapt a FFI interface to the 
target platform (boiler plate code to detect a target change at image 
startup, default code for rebuilding the accessors, and the ability to 
customize that default code).


Thierry

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

[Jan van de Sandt]

Hi Esteban,

Instantiations is also busy porting their VM to 64bits. They have already
created a new API for OStructures so that the offsets are re calculated
based on the platform alignment rules and the VM type [1].

I know Pharo is open source and VA Smalltalk is not. But a bit of
cooperation should be possible I think. Both platforms benefit if libraries
are easy to port and not re-inventing this wheel saves time.

Jan.

[1]
http://www.instantiations.com/docs/862/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html


On Sat, Nov 5, 2016 at 3:10 PM, Esteban Lorenzano 
wrote:

>
> > On 5 Nov 2016, at 12:27, Thierry Goubier 
> wrote:
> >
> > Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :
> >> Hi,
> >>
> >> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
> >> looking good. I'm testing a small library of mine [1] to interface with
> >> LMDB [1], a memory mapped key-value database. Almost all tests are
> >> green. This is great progress!
> >
> > Hi Jan,
> >
> > did you have to change your UFFI definitions to match the 64bits version
> of your lib?
>
> no.
> but structures do change (because of sizes, of course).
> I’m thinking a way to define a generic representation (keeping offsets
> somewhere instead hardcoding it), but for now they have to be redefined for
> each platform.
>
> Esteban
>
> >
> > Thierry
> >
> >> I only ran into one issue, a PrimitiveFailed error with
> >> #basicIdentityHash in the SmallFloat64 class.
> >>
> >> Cheers,
> >> Jan.
> >>
> >> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
> >> [2] https://symas.com/products/lightning-memory-mapped-database/
> >>
> >>
> >> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano <
> esteba...@gmail.com
> >> > wrote:
> >>
> >>VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
> >>
> >>Image here: http://files.pharo.org/get-files/60/pharo-64.zip
> >>
> >>
> >>this is still not official (that’s why is not in official place) so
> >>there are a couple of known problems:
> >>
> >>- version format is different, and that breaks some things in image
> >>that depends on it to know what happens
> >>- command line is different and probably you’ll need to play a bit
> >>with options (one or two dashes).
> >>- UFFI has some failing tests (but most of it works).
> >>
> >>I would appreciate some help to report and/or fix the emerging
> >>problems.
> >>
> >>cheers,
> >>Esteban
> >>
> >>>On 28 Oct 2016, at 10:39, Thierry Goubier
> >>>>
> wrote:
> >>>
> >>>Hi all,
> >>>
> >>>anybody knows how to get (and test) the 64bits version of the
> >>>Pharo vm and image?
> >>>
> >>>Thanks,
> >>>
> >>>Thierry
> >>
> >>
> >
> >
>
>
>

[Pharo-dev] Newbie(ish) Question on SVG with Athens / Roassal / Spec

[Graham McLeod]

Hi

I am contemplating moving an old Pharo app (1.4 vintage) which used 
Morphic heavily into the new Pharo world (Pharo 5).
One of the options is to move a proprietary vector graphic 
implementation which draws symbols to SVG.


Looking for examples / documentation on the use of SVG (external files, 
not image defined paths) has been very frustrating.
All examples I have found have been old and none of the file based / 
load ones work.


Can anyone please point me to good documentation / examples?
I want to understand how one can use:
SVG with Athens
SVG with Spec
SVG loaded from a file with Roassal

Thanks in advance.

Graham
<>

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

[stepharo]

Hi jan


will you contact to add Pharo to the list of languages because this is 
good for us to be in this list.



Stef


Le 5/11/16 à 13:55, Jan van de Sandt a écrit :

Hi Sven,

LMDB is a lean, mean and very fast storage engine. One limitation is 
that you need a 64bit proces before you can store more than 2GB of 
data. That was a downside for me until very recently :-)


LMDB is a low level key-value storage engine that runs on a single 
host. But if that is what you are looking for it seems pretty good. I 
haven't used it in any production systems yet. But it is used as a 
storage engine in quite a few open source projects. For example OpenLDAP.


Jan.

On Sat, Nov 5, 2016 at 1:43 PM, Jan van de Sandt > wrote:


Hi,

The only thing I had to do was to regenerate the accessors of the
structure classes MDBValue and MDBStat. The offsets for the fields
are different on 32 versus 64 bit systems. Perhaps we can think of
a way to generate the field accessors of structure classes such
that they work in both environments.

For now just you can just use #rebuildFieldAccessors

Jan.

On Sat, Nov 5, 2016 at 12:27 PM, Thierry Goubier
> wrote:

Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :

Hi,

With the latest 64bits VM (201611042126) and image (60282)
UFFI is also
looking good. I'm testing a small library of mine [1] to
interface with
LMDB [1], a memory mapped key-value database. Almost all
tests are
green. This is great progress!


Hi Jan,

did you have to change your UFFI definitions to match the
64bits version of your lib?

Thierry

I only ran into one issue, a PrimitiveFailed error with
#basicIdentityHash in the SmallFloat64 class.

Cheers,
Jan.

[1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB

[2]
https://symas.com/products/lightning-memory-mapped-database/



On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano

>>
wrote:

VM here:
http://bintray.com/estebanlm/pharo-vm/build#files/

>
Image here:
http://files.pharo.org/get-files/60/pharo-64.zip

>

this is still not official (that’s why is not in
official place) so
there are a couple of known problems:

- version format is different, and that breaks some
things in image
that depends on it to know what happens
- command line is different and probably you’ll need
to play a bit
with options (one or two dashes).
- UFFI has some failing tests (but most of it works).

I would appreciate some help to report and/or fix the
emerging
problems.

cheers,
Esteban

On 28 Oct 2016, at 10:39, Thierry Goubier

>> wrote:

Hi all,

anybody knows how to get (and test) the 64bits
version of the
Pharo vm and image?

Thanks,

Thierry

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

[Esteban Lorenzano]

> On 5 Nov 2016, at 12:27, Thierry Goubier  wrote:
> 
> Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :
>> Hi,
>> 
>> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
>> looking good. I'm testing a small library of mine [1] to interface with
>> LMDB [1], a memory mapped key-value database. Almost all tests are
>> green. This is great progress!
> 
> Hi Jan,
> 
> did you have to change your UFFI definitions to match the 64bits version of 
> your lib?

no. 
but structures do change (because of sizes, of course). 
I’m thinking a way to define a generic representation (keeping offsets 
somewhere instead hardcoding it), but for now they have to be redefined for 
each platform.

Esteban

> 
> Thierry
> 
>> I only ran into one issue, a PrimitiveFailed error with
>> #basicIdentityHash in the SmallFloat64 class.
>> 
>> Cheers,
>> Jan.
>> 
>> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
>> [2] https://symas.com/products/lightning-memory-mapped-database/
>> 
>> 
>> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano > > wrote:
>> 
>>VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>>
>>Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>>
>> 
>>this is still not official (that’s why is not in official place) so
>>there are a couple of known problems:
>> 
>>- version format is different, and that breaks some things in image
>>that depends on it to know what happens
>>- command line is different and probably you’ll need to play a bit
>>with options (one or two dashes).
>>- UFFI has some failing tests (but most of it works).
>> 
>>I would appreciate some help to report and/or fix the emerging
>>problems.
>> 
>>cheers,
>>Esteban
>> 
>>>On 28 Oct 2016, at 10:39, Thierry Goubier
>>>> wrote:
>>> 
>>>Hi all,
>>> 
>>>anybody knows how to get (and test) the 64bits version of the
>>>Pharo vm and image?
>>> 
>>>Thanks,
>>> 
>>>Thierry
>> 
>> 
> 
> 

Re: [Pharo-dev] roundTo: strange behavior

[werner kassens]

Hi,
fwiw when i redid that #testIfCompletelyBroken i noticed a sort of bug 
in that new #round: - well, i think its a feature -, but i should 
probably mention it nevertheless:

1.15 round:1. "1.1""down"
1.25 round:1. "1.3""up"
1.35 round:1. "1.4""up"
1.45 round:1. "1.4""down"
1.55 round:1. "1.6""up"
1.65 round:1. "1.6""down"
btw the same happens with #printShowingDecimalPlaces: (which is 
unchanged, happens eg also in 4.0).


if one wants to change this to the normal behaviour, i'd guess one could 
do it perhaps by using #asMinimalDecimalFraction instead of #asFraction 
in #round:


i have to admit that i have no problems at all with this idiosyncrasy 
and would _not use #asMinimalDecimalFraction in #round: for these reasons:
1. i see it as a poor mans round-to-even (this bankers rounding is done 
so that the sum of rounded numbers does not have an upward bias in 
relation to the sum of the original unrounded numbers).
2. although i havent tested it, i assume #asMinimalDecimalFraction is 
noticeably slower than #asFraction, because the former one has to use a 
#whileFalse: iteration.
3. round-to-even imprints a definite structure on eg random-numbers, the 
structure of the new #round: is at least less simple & does not produce 
too many even decimals, insofar it's even a rich mans round-to-even (in 
a way a non-random, hence repeatable, stochastic rounding). normal 
rounding of course introduces an even less wanted upward bias.
But  perhaps somebody else wants to have a more predictable 
behaviour of #round:?

werner

On 11/04/2016 10:26 PM, werner kassens wrote:

Hi Stephane,
i uploaded a 
SLICE-Issue-15471-Cant-round-Float-fmax-to-2-decimal-places-WernerKassens.2 
to the inbox with these changes:
i corrected RandomTest>>testIfCompletelyBroken, completed tests with 
some border cases and the usual specifications, and added your comment 
to Float>>round:. 

Re: [Pharo-dev] pillar highlight text in code

[Nicolai Hess]

2016-11-05 13:41 GMT+01:00 stepharo :

> Yes I should fix them.
>
>
> Are you working on this right now? Otherwise I can do it too.
And I was about to create new screenshots for that chapter. Just tell if
you would need them or if you are
about to change them yourself.



>
> Le 3/11/16 à 23:52, Nicolai Hess a écrit :
>
>
>
> 2016-11-03 23:50 GMT+01:00 Nicolai Hess :
>
>> Can we highlight a piece of code?
>> In the updated PBE (Reflection chapter) there is the text:
>> "Change the definition of Integer>>>factorial by inserting the underlined
>> expression as shown below"
>> But I can not see the "underline" in the code example. Is it even
>> possible to add such text properties to a "code-style" formatted text ?
>>
>> BTW, the method name is wrong (in both places)
>> Integer>>#factorial
>> not
>> Integer>>>factorial
>>
>
>
> actually all code examples in that chapter uses
> >>>
> instead of
> >>#
>
>
>

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

[Jan van de Sandt]

Hi Sven,

LMDB is a lean, mean and very fast storage engine. One limitation is that
you need a 64bit proces before you can store more than 2GB of data. That
was a downside for me until very recently :-)

LMDB is a low level key-value storage engine that runs on a single host.
But if that is what you are looking for it seems pretty good. I haven't
used it in any production systems yet. But it is used as a storage engine
in quite a few open source projects. For example OpenLDAP.

Jan.

On Sat, Nov 5, 2016 at 1:43 PM, Jan van de Sandt  wrote:

> Hi,
>
> The only thing I had to do was to regenerate the accessors of the
> structure classes MDBValue and MDBStat. The offsets for the fields are
> different on 32 versus 64 bit systems. Perhaps we can think of a way to
> generate the field accessors of structure classes such that they work in
> both environments.
>
> For now just you can just use #rebuildFieldAccessors
>
> Jan.
>
> On Sat, Nov 5, 2016 at 12:27 PM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :
>>
>>> Hi,
>>>
>>> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
>>> looking good. I'm testing a small library of mine [1] to interface with
>>> LMDB [1], a memory mapped key-value database. Almost all tests are
>>> green. This is great progress!
>>>
>>
>> Hi Jan,
>>
>> did you have to change your UFFI definitions to match the 64bits version
>> of your lib?
>>
>> Thierry
>>
>> I only ran into one issue, a PrimitiveFailed error with
>>> #basicIdentityHash in the SmallFloat64 class.
>>>
>>> Cheers,
>>> Jan.
>>>
>>> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
>>> [2] https://symas.com/products/lightning-memory-mapped-database/
>>>
>>>
>>> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano >> > wrote:
>>>
>>> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>>> 
>>> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>>> 
>>>
>>> this is still not official (that’s why is not in official place) so
>>> there are a couple of known problems:
>>>
>>> - version format is different, and that breaks some things in image
>>> that depends on it to know what happens
>>> - command line is different and probably you’ll need to play a bit
>>> with options (one or two dashes).
>>> - UFFI has some failing tests (but most of it works).
>>>
>>> I would appreciate some help to report and/or fix the emerging
>>> problems.
>>>
>>> cheers,
>>> Esteban
>>>
>>> On 28 Oct 2016, at 10:39, Thierry Goubier
 >
 wrote:

 Hi all,

 anybody knows how to get (and test) the 64bits version of the
 Pharo vm and image?

 Thanks,

 Thierry

>>>
>>>
>>>
>>
>>
>

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

[Jan van de Sandt]

Hi,

The only thing I had to do was to regenerate the accessors of the structure
classes MDBValue and MDBStat. The offsets for the fields are different on
32 versus 64 bit systems. Perhaps we can think of a way to generate the
field accessors of structure classes such that they work in both
environments.

For now just you can just use #rebuildFieldAccessors

Jan.

On Sat, Nov 5, 2016 at 12:27 PM, Thierry Goubier 
wrote:

> Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :
>
>> Hi,
>>
>> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
>> looking good. I'm testing a small library of mine [1] to interface with
>> LMDB [1], a memory mapped key-value database. Almost all tests are
>> green. This is great progress!
>>
>
> Hi Jan,
>
> did you have to change your UFFI definitions to match the 64bits version
> of your lib?
>
> Thierry
>
> I only ran into one issue, a PrimitiveFailed error with
>> #basicIdentityHash in the SmallFloat64 class.
>>
>> Cheers,
>> Jan.
>>
>> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
>> [2] https://symas.com/products/lightning-memory-mapped-database/
>>
>>
>> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano > > wrote:
>>
>> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>> 
>> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>> 
>>
>> this is still not official (that’s why is not in official place) so
>> there are a couple of known problems:
>>
>> - version format is different, and that breaks some things in image
>> that depends on it to know what happens
>> - command line is different and probably you’ll need to play a bit
>> with options (one or two dashes).
>> - UFFI has some failing tests (but most of it works).
>>
>> I would appreciate some help to report and/or fix the emerging
>> problems.
>>
>> cheers,
>> Esteban
>>
>> On 28 Oct 2016, at 10:39, Thierry Goubier
>>> >
>>> wrote:
>>>
>>> Hi all,
>>>
>>> anybody knows how to get (and test) the 64bits version of the
>>> Pharo vm and image?
>>>
>>> Thanks,
>>>
>>> Thierry
>>>
>>
>>
>>
>
>

Re: [Pharo-dev] pillar highlight text in code

[stepharo]

Yes I should fix them.



Le 3/11/16 à 23:52, Nicolai Hess a écrit :



2016-11-03 23:50 GMT+01:00 Nicolai Hess >:


Can we highlight a piece of code?
In the updated PBE (Reflection chapter) there is the text:
"Change the definition of Integer>>>factorial by inserting the
underlined expression as shown below"
But I can not see the "underline" in the code example. Is it even
possible to add such text properties to a "code-style" formatted
text ?

BTW, the method name is wrong (in both places)
Integer>>#factorial
not
Integer>>>factorial



actually all code examples in that chapter uses
>>>
instead of
>>#

Re: [Pharo-dev] Keyboard list item navigation in Sender browser is strange

[stepharo]

Denis showed me that this is the normal behavior since the list 
indicates where the mouse is.



Le 3/11/16 à 21:54, stepharo a écrit :

Hi guys

If I click on an item in the message browser. The previous item gets 
deselected and the new one selected.


Now if I use arrows, the previous items is greyed out.

Are you seeing the same?


Stef

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

[Sven Van Caekenberghe]

Wow, this LMDB thing seems pretty cool.

Actually, it sounds as if there are no downsides.

What are the limitations ?

> On 5 Nov 2016, at 12:12, Jan van de Sandt  wrote:
> 
> Hi,
> 
> With the latest 64bits VM (201611042126) and image (60282) UFFI is also 
> looking good. I'm testing a small library of mine [1] to interface with LMDB 
> [1], a memory mapped key-value database. Almost all tests are green. This is 
> great progress!
> 
> I only ran into one issue, a PrimitiveFailed error with #basicIdentityHash in 
> the SmallFloat64 class.
> 
> Cheers,
> Jan.
> 
> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
> [2] https://symas.com/products/lightning-memory-mapped-database/
>  
> 
> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano  
> wrote:
> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
> 
> this is still not official (that’s why is not in official place) so there are 
> a couple of known problems: 
> 
> - version format is different, and that breaks some things in image that 
> depends on it to know what happens
> - command line is different and probably you’ll need to play a bit with 
> options (one or two dashes). 
> - UFFI has some failing tests (but most of it works).
> 
> I would appreciate some help to report and/or fix the emerging problems. 
> 
> cheers, 
> Esteban
> 
>> On 28 Oct 2016, at 10:39, Thierry Goubier  wrote:
>> 
>> Hi all,
>> 
>> anybody knows how to get (and test) the 64bits version of the Pharo vm and 
>> image?
>> 
>> Thanks,
>> 
>> Thierry
> 
> 

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

[Jan van de Sandt]

Hi,

With the latest 64bits VM (201611042126) and image (60282) UFFI is also
looking good. I'm testing a small library of mine [1] to interface with
LMDB [1], a memory mapped key-value database. Almost all tests are green.
This is great progress!

I only ran into one issue, a PrimitiveFailed error with #basicIdentityHash
in the SmallFloat64 class.

Cheers,
Jan.

[1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
[2] https://symas.com/products/lightning-memory-mapped-database/


On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano 
wrote:

> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>
> this is still not official (that’s why is not in official place) so there
> are a couple of known problems:
>
> - version format is different, and that breaks some things in image that
> depends on it to know what happens
> - command line is different and probably you’ll need to play a bit with
> options (one or two dashes).
> - UFFI has some failing tests (but most of it works).
>
> I would appreciate some help to report and/or fix the emerging problems.
>
> cheers,
> Esteban
>
> On 28 Oct 2016, at 10:39, Thierry Goubier 
> wrote:
>
> Hi all,
>
> anybody knows how to get (and test) the 64bits version of the Pharo vm and
> image?
>
> Thanks,
>
> Thierry
>
>
>

[Pharo-dev] [pharo-project/pharo-core] 189d2e: 60282

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 189d2e1cd910e3d24861d6baf50c05acde27207c
  
https://github.com/pharo-project/pharo-core/commit/189d2e1cd910e3d24861d6baf50c05acde27207c
  Author: Jenkins Build Server 
  Date:   2016-11-05 (Sat, 05 Nov 2016)

  Changed paths:
M 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F24%5F1_.st
A 
ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F24%5F2_.st
M FFI-Kernel.package/extension/ByteArray/instance/asExternalPointer.st
A 
Kernel-Tests.package/ProcessSpecificTest.class/instance/testing/testDynamicVariableRemovedAfterUse.st
M Kernel.package/DynamicVariable.class/instance/accessing/value_during_.st
M 
Metacello-Core.package/MetacelloPlatform.class/instance/github%2Fbitbucket 
support/fileDirectoryClass.st
M 
Metacello-Core.package/MetacelloPlatform.class/instance/system/suspendSystemUpdateEventsDuring_.st
M 
Metacello-PharoCommonPlatform.package/MetacelloPharoCommonPlatform.class/instance/git-based
 http repo support/downloadBasicFile_to_username_pass_.st
M 
Metacello-PharoCommonPlatform.package/MetacelloPharoCommonPlatform.class/instance/github
 support/extractRepositoryFrom_to_.st
M 
Metacello-PharoCommonPlatform.package/MetacelloPharoCommonPlatform.class/instance/utilities/compiler.st
M Morphic-Core.package/HandMorph.class/instance/private 
events/generateMouseEvent_.st
M 
Morphic-Core.package/PasteUpMorph.class/instance/accessing/currentWindow.st
M Nautilus.package/PackageTreeModel.class/instance/help-text/helpTextFor_.st
M RPackage-Core.package/RPackageOrganizer.class/instance/system 
integration/registerInterestToAnnouncer_.st
M 
RPackage-Tests.package/RPackageRenameTest.class/instance/running/tearDown.st
M RPackage-Tests.package/RPackageTagTest.class/instance/running/tearDown.st
M RPackage-Tests.package/RPackageTest.class/instance/running/tearDown.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60281.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60282.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60281.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60282.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M System-Sound.package/Beeper.class/instance/play interface/play.st
M 
Tool-ImageCleaner.package/ImageCleaner.class/instance/api/cleanUpForRelease.st
M 
Traits.package/TClassDescription.class/instance/private/notifyRepackage_method_oldProtocol_newProtocol_.st
M UnifiedFFI.package/FFISizeT.class/class/converting/asExternalTypeOn_.st

  Log Message:
  ---
  60282
19289 asClass users are still in the system
https://pharo.fogbugz.com/f/cases/19289

19248 ByteArray>>#asExternalPointer uses fixed 32bites pointer size
https://pharo.fogbugz.com/f/cases/19248

19278 Dynamic variables should be removed from the environment when no longer 
needed
https://pharo.fogbugz.com/f/cases/19278

http://files.pharo.org/image/60/60282.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60282
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 5ac041: 60281

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 5ac0416ed4c7f6ff27d8771fad45afd4220b6692
  
https://github.com/pharo-project/pharo-core/commit/5ac0416ed4c7f6ff27d8771fad45afd4220b6692
  Author: Jenkins Build Server 
  Date:   2016-11-05 (Sat, 05 Nov 2016)

  Changed paths:
M Nautilus.package/AbstractNautilusUI.class/instance/drag and 
drop/dropInAPackage_into_.st
A Nautilus.package/extension/Class/instance/dropIn_forNautilusUI_.st
A 
Nautilus.package/extension/CompiledMethod/instance/dropIn_forNautilusUI_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60280.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60281.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60280.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60281.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60281
19302 Drag and drop a method to another package to make an extension in 
Nautilus does not work
https://pharo.fogbugz.com/f/cases/19302

19292 referencePosition, originalCenter and originalAngle can be turned into 
instance variables in CircleMorph
https://pharo.fogbugz.com/f/cases/19292

19241 Bag flatCollect
https://pharo.fogbugz.com/f/cases/19241

http://files.pharo.org/image/60/60281.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60281
  Home:   https://github.com/pharo-project/pharo-core

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

[Esteban Lorenzano]

this is more a question for vm-dev list I think. 
I have not idea on how to overcome this problem… doesn’t look very possible, 
thinking in general. Maybe in freebsd (who I also do not know at all) there is 
another way to change limits?
also, I think itimer could be less efficient, but should be possible… crashing 
do not looks like a nice output :)

Esteban

> On 4 Nov 2016, at 23:56, Petr Fischer  wrote:
> 
> Also on FreeBSD, there is no security/limits config, so on FreeBSD, I am not 
> able to run heartbeat VM as normal user at all :(
> 
> Ins't there any other solution? Why "realtime" threads? Isn't possible to run 
> "heartbeat" thread with normal priority and all other threads with lower 
> priorities to provide the same behaviour?
> 
> How to deploy application based on Pharo to the normal (UNIX) users, if 
> security reconfiguration is needed?
> 
> pf
> 
> P.S. VM wihout heartbeat is crashing on FreeBSD randomly with error "stack 
> page bytes 4096 available headroom 2788 minimum unused headroom 3020" :(
> 
> 
>> BTW, the threaded version requires to be run as super user because it
>> tries to do a pthread_setschedparam(). I tried to fiddle with
>> /etc/security/limits.conf... but it's not something fancy to do...
>> 
>> Best regards,
>> 
>> Casimiro Barreto
>> 
>> Em 03-11-2016 13:53, Thierry Goubier escreveu:
>>> Hi Esteban,
>>> 
>>> Another question about Pharo 64 bits.
>>> 
>>> Why are libgit/libSDL/libssh included in the vm? Ubuntu 16.10 provides
>>> them with the same version numbers, more or less.
>>> (libgit2 is so.0.24.0 on ubuntu instead of so.0.24.2 in the pharo vm,
>>> SDL and ssh are the exact same versions).
>>> 
>>> Collectively, those three libs are ~ 5M.
>>> 
>>> Thierry
>>> 
>>> 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano >> >:
>>> 
>>>VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>>>
>>>Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>>>
>>> 
>>>this is still not official (that’s why is not in official place)
>>>so there are a couple of known problems: 
>>> 
>>>- version format is different, and that breaks some things in
>>>image that depends on it to know what happens
>>>- command line is different and probably you’ll need to play a bit
>>>with options (one or two dashes). 
>>>- UFFI has some failing tests (but most of it works).
>>> 
>>>I would appreciate some help to report and/or fix the emerging
>>>problems. 
>>> 
>>>cheers, 
>>>Esteban
>>> 
On 28 Oct 2016, at 10:39, Thierry Goubier
> wrote:
 
Hi all,
 
anybody knows how to get (and test) the 64bits version of the
Pharo vm and image?
 
Thanks,
 
Thierry
>>> 
>>> 
>> 
>> 
>> -- 
>> The information contained in this message is confidential and intended
>> to the recipients specified in the headers. If you received this message
>> by error, notify the sender immediately. The unauthorized use,
>> disclosure, copy or alteration of this message are strictly forbidden
>> and subjected to civil and criminal sanctions.
>> 
>> ==
>> 
>> This email may be signed using PGP key *ID: 0x4134A417*
> 
> 
> 
>