Le 03/05/2017 à 23:50, Eliot Miranda a écrit :
On May 3, 2017, at 1:52 PM, Thierry Goubier wrote:
Le 03/05/2017 à 22:39, Eliot Miranda a écrit :
Hi Thierry,
Hi Eliot,
On May 3, 2017, at 1:20 PM, Thierry Goubier
wrote:
I'm now
> On May 3, 2017, at 1:52 PM, Thierry Goubier wrote:
>
>> Le 03/05/2017 à 22:39, Eliot Miranda a écrit :
>> Hi Thierry,
>
> Hi Eliot,
>
>>> On May 3, 2017, at 1:20 PM, Thierry Goubier
>>> wrote:
>>>
>>> I'm now chasing an old 64 bits vm
Hi Esteban,
On 3 May 2017 at 13:22, Esteban Lorenzano wrote:
>
>> On 3 May 2017, at 12:38, Alistair Grant wrote:
>>
>> Hi Esteban,
>>
>> $ curl http://get.pharo.org/64/60+vmLatest | bash
>> $ ./pharo --version
>>
>> Shows the build version as:
>>
>>
Le 03/05/2017 à 22:39, Eliot Miranda a écrit :
Hi Thierry,
Hi Eliot,
On May 3, 2017, at 1:20 PM, Thierry Goubier
wrote:
I'm now chasing an old 64 bits vm from files.pharo.org. All the new
ones for the past 2 months segfault. Would anybody have kept a ~ 2
month
Hi Thierry,
> On May 3, 2017, at 1:20 PM, Thierry Goubier wrote:
>
> I'm now chasing an old 64 bits vm from files.pharo.org. All the new ones for
> the past 2 months segfault. Would anybody have kept a ~ 2 month old 64 bits
> vm (threaded or not) for linux
I'm now chasing an old 64 bits vm from files.pharo.org. All the new ones
for the past 2 months segfault. Would anybody have kept a ~ 2 month old
64 bits vm (threaded or not) for linux somewhere?
Regards,
Thierry
Le 03/05/2017 à 21:58, Nicolas Cellier a écrit :
2017-05-03 17:45 GMT+02:00
2017-05-03 17:45 GMT+02:00 Eliot Miranda :
>
>
> > On May 3, 2017, at 4:22 AM, Esteban Lorenzano
> wrote:
> >
> >
> >> On 3 May 2017, at 12:38, Alistair Grant wrote:
> >>
> >> Hi Esteban,
> >>
> >> $ curl
On 2017-05-03 18:05, Denis Kudriashov wrote:
2017-05-03 16:28 GMT+02:00 Raffaello Giulietti
>:
Sorry, Phil, this is (currently) not open source software for many
reasons. Depending on how Pharo moves in the
2017-05-03 16:09 GMT+02:00 p...@highoctane.be :
> 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.
>
I tried load JNIPort today. It is not loaded/working on Pharo6 because it
is based on
2017-05-03 16:28 GMT+02:00 Raffaello Giulietti <
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?
> On May 3, 2017, at 4:22 AM, Esteban Lorenzano wrote:
>
>
>> On 3 May 2017, at 12:38, Alistair Grant wrote:
>>
>> Hi Esteban,
>>
>> $ curl http://get.pharo.org/64/60+vmLatest | bash
>> $ ./pharo --version
>>
>> Shows the build version as:
>>
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
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
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
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?
cheers -ben
On Wed, May 3, 2017 at 8:32 PM, Raffaello Giulietti <
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
Branch: refs/tags/60480
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 74e84370bac8c84a7f4bc821b2d5c6e506235c63
https://github.com/pharo-project/pharo-core/commit/74e84370bac8c84a7f4bc821b2d5c6e506235c63
Author: Jenkins Build Server
Date:
On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti <
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
> On 3 May 2017, at 12:38, Alistair Grant wrote:
>
> Hi Esteban,
>
> $ curl http://get.pharo.org/64/60+vmLatest | bash
> $ ./pharo --version
>
> Shows the build version as:
>
> VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
> Date: Tue May 2
Hi Esteban,
$ curl http://get.pharo.org/64/60+vmLatest | bash
$ ./pharo --version
Shows the build version as:
VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Date: Tue May 2 16:26:41 2017 -0700 $
Does that mean we should be building from the opensmalltalk repository
mmm… yes. But then… it has to be something like that.
maybe Eliot can help here.
Esteban
> On 3 May 2017, at 11:01, Raffaello Giulietti
> wrote:
>
> No, that does not work, as I reported:
>
>
> On 2017-05-03 10:33, Raffaello Giulietti wrote:
> > The current
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
Hi,
On Wed, May 3, 2017 at 10:43 AM, Clément Bera
wrote:
> Hi
>
> Try resizing the window and clicking inside it a couple times. It usually
> refreshes the surface correctly and avoids the need to force quit.
>
I tried to click a few time but nothing happened.
Next time
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:
>
>
>
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
Branch: refs/tags/60479
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 1d7edd94bbc490de294a068fca16e42829b8ca1c
https://github.com/pharo-project/pharo-core/commit/1d7edd94bbc490de294a068fca16e42829b8ca1c
Author: Jenkins Build Server
Date:
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.
>
>
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:
Hi
Try resizing the window and clicking inside it a couple times. It usually
refreshes the surface correctly and avoids the need to force quit.
I think it happens to other people too, it seems it's exclusive to Mac OS X.
Best,
On Wed, May 3, 2017 at 10:23 AM, Andrei Chis
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.
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
Also good news that image drag and drop into latest VM works fine again
2017-05-03 10:10 GMT+02:00 Esteban Lorenzano :
> I know, but cannot wait for promoting… is “stable enough”.
> Also… problem is not present on other flavours so I guess is an image
> problem. Guille
Hi,
With the latest moose image based on Pharo 6 and vm (32 bit) sometimes when
I resize the main window or enter full screen mode on MacOS the window
becomes totally white and does not recover:[image: Inline image 1]
I need to force quit the image. Also this happens not that often and quite
I know, but cannot wait for promoting… is “stable enough”.
Also… problem is not present on other flavours so I guess is an image problem.
Guille worked a bit on it but we need to review some more.
Esteban
> On 3 May 2017, at 10:03, Denis Kudriashov wrote:
>
> Hi.
>
>
Hi.
Black screen on startup is still there on Mac Sierra 32 bits VM
2017-05-03 9:43 GMT+02:00 Esteban Lorenzano :
> in 15min, I will promote latest VM to stable VM.
> The new stable VM has a lot of bugfixes, notably:
>
> - compactor works
> - Cairo and Surface plugin now
in 15min, I will promote latest VM to stable VM.
The new stable VM has a lot of bugfixes, notably:
- compactor works
- Cairo and Surface plugin now can coexist (and it does not crashes)
- lot of other small things
cheers,
Esteban
Branch: refs/tags/60478
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 6e92eb6cb6283b613727ef54630e32d3403e3f88
https://github.com/pharo-project/pharo-core/commit/6e92eb6cb6283b613727ef54630e32d3403e3f88
Author: Jenkins Build Server
Date:
40 matches
Mail list logo