[Pharo-dev] PrimitiveFailed: primitive #primLocalAddress in NetNameResolver class failed [FreeBSD]

[Petr Fischer]

Hello,

just tested latest 32b Linux spur VM "stable-threaded-20170503" with latest 6.0 
image "60494" (from files.pharo.com) under FreeBSD with linux compatibility 
layer switched on.

Good part - now, it's running wihtout need of real time threads (no need to run 
under root, oh yes!) and it runs near 2x speed in some tests, just wow!

But, this exception occurs often:
PrimitiveFailed: primitive #primLocalAddress in NetNameResolver class failed
details: https://pastebin.com/raw/bdjDW6YR

Whats wrong? Some news/changes in SocketPlugin?

Thanks! pf

Re: [Pharo-dev] PrimitiveFailed: primitive #primLocalAddress in NetNameResolver class failed [FreeBSD]

[Petr Fischer]

It's not jail, just core FreeBSD system (I will test jails later).

Networking is still the same, Pharo 5 is OK.

/etc/hosts: 
::1ilocalhost localhost.my.domain
127.0.0.1   localhost localhost.my.domain
127.0.0.1   pf-bsd pf-bsd.localdomain pf-bsd.local

ifconfig:
em0: flags=8c02 metric 0 mtu 1500

options=4019b
ether b8:6b:23:38:f8:7d
nd6 options=29
media: Ethernet autoselect
status: no carrier
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21
groups: lo
wlan0: flags=8843 metric 0 mtu 1500
ether 30:10:b3:77:b8:58
inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 
nd6 options=29
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
ssid "pf's Network" channel 1 (2412 MHz 11g ht/20) bssid 
f0:79:59:d2:7a:00
regdomain 106 indoor ecm authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 20 bmiss 7
scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme
burst roaming MANUAL
groups: wlan



> 
> > On 19. May 2017, at 03:27, Petr Fischer  wrote:
> > 
> > Hello,
> 
> 
> 
> > But, this exception occurs often:
> > PrimitiveFailed: primitive #primLocalAddress in NetNameResolver class failed
> > details: https://pastebin.com/raw/bdjDW6YR
> 
> 
> How does the networking look in your jail? Which interfaces and IP addresses 
> do you have?
> 
> holger
> 
> 

[Pharo-dev] Download Pharo for GNU/Linux - wrong info on that page

[Petr Fischer]

Hello, this page:

https://pharo.org/gnu-linux-installation

1) in examples, there is a usage of "yum-config-manager" command, add a note 
that "yum-utils" package must be installed

2) correct all paths to the opensuse repos please, at least this is wrong:

CentOS 7 (only 64bit):
http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/CentOS_7/devel:languages:pharo:latest.repo

Correct URL is probably:
http://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/CentOS_7/devel:languages:pharo:stable.repo

pf

Re: [Pharo-dev] New Year Wishlist (2018) ?

[Petr Fischer]

- stability
- bloc
- some sort of pretty cool and fast concurrent transactional object persistence 
:)


> Hi everybody, 
> 
> This looks like a good moment of the year to ask all of you what would you 
> want to see in Pharo next year. 
> Features, improvements, radical changes, etc…. whatever you want.
> 
> Of course, this list will not be a roadmap and it does not means we will 
> implement all of it (as always, time drives our possibilities), but is a good 
> moment for us a a community to check where we are and where we wan to go next 
> :)
> 
> So, let’s those wishes come! 
> 
> cheers, 
> Esteban

[Pharo-dev] Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

[Petr Fischer]

Hello!

I assume that Ctrl+W is a widely used keyboard shortcut for closing windows or 
a tab, if the window is "tabbed" (it works in web browsers, some desktops, 
Linux, IE, Mac OS X...).

But when I start up some exploration session in GT inspector,  I have several 
tabs opened in a second - then, after Ctrl+W, not the actual tab, but the whole 
window is immediately closed, gosh...
Same situation in "window groups" (when you created tabbed window group from 
browser/Calypso) - Ctrl+W behaves weird.

Is everyone in comfort with the idea that Ctrl+W should close the actual tab, 
and if there is no tab in the window (or actual tab is the last tab), then 
close the window?

Tested in Pharo 5, 6 and 6.1.

pf

Re: [Pharo-dev] Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

[Petr Fischer]

It's completely weird:

1) first Ctrl+W closes the "content" of the tab
2) second Ctrl+W closes whole tabbed window

Look at thos video: https://youtu.be/MUcYNGnDAR8

pf

> Hi.
> 
> Are you sure that Calypso closes full window instead of single tab?
> Because I use it all the time and it works for me in the way you described.
> 
> 2018-03-19 10:07 GMT+01:00 Petr Fischer :
> 
> > Hello!
> >
> > I assume that Ctrl+W is a widely used keyboard shortcut for closing
> > windows or a tab, if the window is "tabbed" (it works in web browsers, some
> > desktops, Linux, IE, Mac OS X...).
> >
> > But when I start up some exploration session in GT inspector,  I have
> > several tabs opened in a second - then, after Ctrl+W, not the actual tab,
> > but the whole window is immediately closed, gosh...
> > Same situation in "window groups" (when you created tabbed window group
> > from browser/Calypso) - Ctrl+W behaves weird.
> >
> > Is everyone in comfort with the idea that Ctrl+W should close the actual
> > tab, and if there is no tab in the window (or actual tab is the last tab),
> > then close the window?
> >
> > Tested in Pharo 5, 6 and 6.1.
> >
> > pf
> >
> >

Re: [Pharo-dev] Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

[Petr Fischer]

> On 19 March 2018 at 17:07, Petr Fischer  wrote:
> 
> > Hello!
> >
> > I assume that Ctrl+W is a widely used keyboard shortcut for closing
> > windows or a tab, if the window is "tabbed" (it works in web browsers, some
> > desktops, Linux, IE, Mac OS X...).
> >
> > But when I start up some exploration session in GT inspector,  I have
> > several tabs opened in a second - then, after Ctrl+W, not the actual tab,
> > but the whole window is immediately closed, gosh...
> > Same situation in "window groups" (when you created tabbed window group
> > from browser/Calypso) - Ctrl+W behaves weird.
> >
> > Is everyone in comfort with the idea that Ctrl+W should close the actual
> > tab, and if there is no tab in the window (or actual tab is the last tab),
> > then close the window?
> >
> 
> Actually I never knew that shortcut, but I will now.
> I see it works that way in both Chrome and InternetExplorer and web
> browsers are a good benchmark.
> But its not "critical" so I think it will be tough convincing someone to
> work on it for 5.0, 6.0, 6.1.
> For 7 it sounds like a good idea.

Should I enter the issue to the Fogbuz (for Pharo 7)?

pf

> 
> cheers -ben
> 
> 
> >
> > Tested in Pharo 5, 6 and 6.1.
> >
> > pf
> >
> >

Re: [Pharo-dev] Ctrl+W in tabbed windows (GT inspector, browser/Calypso)

[Petr Fischer]

> Ok. I see.
> 
> It is not scenario which I used.
> Now I fixed it in dev version

Wow that's fast! Next time I will use github issues for it (probably the 
preferred way).
Thanks.

> 2018-03-19 13:32 GMT+01:00 Petr Fischer :
> 
> > It's completely weird:
> >
> > 1) first Ctrl+W closes the "content" of the tab
> > 2) second Ctrl+W closes whole tabbed window
> >
> > Look at thos video: https://youtu.be/MUcYNGnDAR8
> >
> > pf
> >
> > > Hi.
> > >
> > > Are you sure that Calypso closes full window instead of single tab?
> > > Because I use it all the time and it works for me in the way you
> > described.
> > >
> > > 2018-03-19 10:07 GMT+01:00 Petr Fischer :
> > >
> > > > Hello!
> > > >
> > > > I assume that Ctrl+W is a widely used keyboard shortcut for closing
> > > > windows or a tab, if the window is "tabbed" (it works in web browsers,
> > some
> > > > desktops, Linux, IE, Mac OS X...).
> > > >
> > > > But when I start up some exploration session in GT inspector,  I have
> > > > several tabs opened in a second - then, after Ctrl+W, not the actual
> > tab,
> > > > but the whole window is immediately closed, gosh...
> > > > Same situation in "window groups" (when you created tabbed window group
> > > > from browser/Calypso) - Ctrl+W behaves weird.
> > > >
> > > > Is everyone in comfort with the idea that Ctrl+W should close the
> > actual
> > > > tab, and if there is no tab in the window (or actual tab is the last
> > tab),
> > > > then close the window?
> > > >
> > > > Tested in Pharo 5, 6 and 6.1.
> > > >
> > > > pf
> > > >
> > > >
> >
> >

[Pharo-dev] Pharo 6.1 for FreeBSD - is available somewhere?

[Petr Fischer]

Hello, is a compiled Pharo VM 64bit for FreeBSD somewhere?

I am sticked with Linux version of Pharo 5 32bit (running it on the FreeBSD by 
linux compatibility layer), because actual Linux Spur 64bit VM is segfaulting 
randomly on FreeBSD.

Maybe some FreeBSD enthusiast's already did it?
I need to start a new project and I want to do it on the current Pharo (Pharo 5 
32b is getting out of date).

On what Linux is default 64bit VM compiled? Ubuntu? CentOS 7? I am asking 
because linux compatibility layer on FreeBSD is based on CentOS 7 libraries.

Thanks! pf

[Pharo-dev] Official packages on pharo.com - broken

[Petr Fischer]

Hello, 

look at this page:
http://pharo.org/gnu-linux-installation

and try to download "libc < 2.15" or "centos" versions.
Both are broken - error message immediately after start:

"This interpreter (vers. 6505) cannot read image file (vers. 6521)."

So, the first impression is really terrible (don't work at all).
Default GNU/Linux download is probably OK.

pf

[Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

[Petr Fischer]

Hello, I got some random segfaults (while loading Seaside) with 32 bit spur vm 
on FreeBSD - can someone (with low level knowledge) decode attached log?
Is this some problem with stack size? Can I fix this?

Log:
http://pastebin.com/raw/NpFUnjh0

There is "**StackOverflow**" lines n the log...

Thanks! pf

Re: [Pharo-dev] Official packages on pharo.com - broken

[Petr Fischer]

  It's due to my obscure OS (‎FreeBSD, latest). They have Linux compatibility (even 64bits soon), so it's nice, but libs are from CentOS6 (now) with glibc 2.12 etc etc. But disfunct downloads on pharo.org is bad. ‎Removing obsolete thinks from official website is not bad idea. My next step is to compile VM myself directly on BSD with clang (and 64bit fast spur soon!), but it's too big step for me now. Thanks to all, rething the download section on Pharo website, or fix builds... pfOd: Peter UhnákOdesláno: pátek, 17. června 2016 14:46Komu: Pharo Development ListOdpovědět: Pharo Development ListPředmět: Re: [Pharo-dev] Official packages on pharo.com - brokenI guess nobody would expect that you would such an old setup with new Pharo?Maybe it should be removed altogether? Why are people using four years old libraries with the latest Pharo?On Fri, Jun 17, 2016 at 1:18 PM, Petr Fischer <petr.fisc...@me.com> wrote:Hello,

look at this page:
http://pharo.org/gnu-linux-installation

and try to download "libc < 2.15" or "centos" versions.
Both are broken - error message immediately after start:

"This interpreter (vers. 6505) cannot read image file (vers. 6521)."

So, the first impression is really terrible (don't work at all).
Default GNU/Linux download is probably OK.

pf

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

[Petr Fischer]

VM version (from https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/):

5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM]
CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab 
Jan 17 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: 
2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016
https://github.com/estebanlm/pharo-vm.git Commit: 
21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: 
Esteban Lorenzano  Jenkins build #498
Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 
GNU/Linux
plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default: 
/usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/]

Image version (from official 5.0 download):

[version] 5.0 #50723

pf

> in fact, this is not related to FFI… but it should be fixed… 
> 
> along with the VM version, which version of Pharo are you using?
> 
> Esteban
> 
> > On 17 Jun 2016, at 14:04, Max Leske  wrote:
> > 
> > Hi Petr,
> > 
> > That looks like a bug with FreeType with our FFI. It should actually have 
> > been fixed but I don’t know if the VM for FreeBSD is up to date. Can you 
> > post the output of “Smalltalk vm version”?
> > 
> > Cheers,
> > Max
> > 
> >> On 17 Jun 2016, at 13:26, Petr Fischer  wrote:
> >> 
> >> Hello, I got some random segfaults (while loading Seaside) with 32 bit 
> >> spur vm on FreeBSD - can someone (with low level knowledge) decode 
> >> attached log?
> >> Is this some problem with stack size? Can I fix this?
> >> 
> >> Log:
> >> http://pastebin.com/raw/NpFUnjh0
> >> 
> >> There is "**StackOverflow**" lines n the log...
> >> 
> >> Thanks! pf
> >> 
> > 
> > 
> 
> 

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

[Petr Fischer]

So... I compiled latest sources (blessed) on CentOS 6.8, fine, moved compiled 
binaries to FreeBSD and tried to load Seaside to the latest 50760 image.
Still stack errors, log here: http://pastebin.com/raw/bf1EpWNt

When I run this on CentOS, everything is fine (loading Seaside, no stack 
errors), but when I run the same on FreeBSD, stack errors (segfaults) occurs.

So... There is something bad on FreeBSD side? Can I debug more?

pf


> Try 50760 from...
> http://files.pharo.org/image/50/
> 
> cheers -ben
> 
> On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer  wrote:
> > VM version (from 
> > https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/):
> >
> > 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM]
> > CoInterpreter VMMaker.oscog-eem.1630 uuid: 
> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016
> > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: 
> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016
> > https://github.com/estebanlm/pharo-vm.git Commit: 
> > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 
> > By: Esteban Lorenzano  Jenkins build #498
> > Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 
> > GNU/Linux
> > plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default: 
> > /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/]
> >
> > Image version (from official 5.0 download):
> >
> > [version] 5.0 #50723
> >
> > pf
> >
> >> in fact, this is not related to FFI… but it should be fixed…
> >>
> >> along with the VM version, which version of Pharo are you using?
> >>
> >> Esteban
> >>
> >> > On 17 Jun 2016, at 14:04, Max Leske  wrote:
> >> >
> >> > Hi Petr,
> >> >
> >> > That looks like a bug with FreeType with our FFI. It should actually 
> >> > have been fixed but I don’t know if the VM for FreeBSD is up to date. 
> >> > Can you post the output of “Smalltalk vm version”?
> >> >
> >> > Cheers,
> >> > Max
> >> >
> >> >> On 17 Jun 2016, at 13:26, Petr Fischer  wrote:
> >> >>
> >> >> Hello, I got some random segfaults (while loading Seaside) with 32 bit 
> >> >> spur vm on FreeBSD - can someone (with low level knowledge) decode 
> >> >> attached log?
> >> >> Is this some problem with stack size? Can I fix this?
> >> >>
> >> >> Log:
> >> >> http://pastebin.com/raw/NpFUnjh0
> >> >>
> >> >> There is "**StackOverflow**" lines n the log...
> >> >>
> >> >> Thanks! pf
> >> >>
> >> >
> >> >
> >>
> >>
> >
> 

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

[Petr Fischer]

Yes there is "PharoVMBuilder buildFreeBSD", but some "cog*" errors occurs... So 
I am still building with "PharoVMSpur32Builder buildUnix32" under Linux 
(CentOS6) and then move compiled vm to my FreeBSD box with Linux compatibility 
layer.

I compiled DEBUG vm version according to your advice and this is gdb output:

Program received signal SIGSEGV, Segmentation fault.
0x080aefc1 in scavengeReferentsOf (referrer=684415032) at 
/home/pf/pharo/pharo-vm-debug/src/vm/gcc3x-cointerp.c:39014
39014   if (((longAt(referent)) & ((classIndexMask()) - 
(isForwardedObjectClassIndexPun( == 0) {

I need to learn a little, how to play this "core C" game in gdb...
What next?

A also compiled PharoS (Pharo Stack) VM, and it's 5x slower, but stable, there 
is no stack errors (or other crashes) like in cog spur vm.

pf


> You could build a debug VM from here
> https://github.com/pharo-project/pharo-vm
> I also glimpsed some FreeBSD build options there you might try.
> cheers -ben
> 
> On Fri, Jun 24, 2016 at 12:05 PM, Petr Fischer  wrote:
> 
> > So... I compiled latest sources (blessed) on CentOS 6.8, fine, moved
> > compiled binaries to FreeBSD and tried to load Seaside to the latest 50760
> > image.
> > Still stack errors, log here: http://pastebin.com/raw/bf1EpWNt
> >
> > When I run this on CentOS, everything is fine (loading Seaside, no stack
> > errors), but when I run the same on FreeBSD, stack errors (segfaults)
> > occurs.
> >
> > So... There is something bad on FreeBSD side? Can I debug more?
> >
> > pf
> >
> >
> > > Try 50760 from...
> > > http://files.pharo.org/image/50/
> > >
> > > cheers -ben
> > >
> > > On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer 
> > wrote:
> > > > VM version (from
> > https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/):
> > > >
> > > > 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM]
> > > > CoInterpreter VMMaker.oscog-eem.1630 uuid:
> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016
> > > > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid:
> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016
> > > > https://github.com/estebanlm/pharo-vm.git Commit:
> > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100
> > By: Esteban Lorenzano  Jenkins build #498
> > > > Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2
> > x86_64 GNU/Linux
> > > > plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default:
> > /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/]
> > > >
> > > > Image version (from official 5.0 download):
> > > >
> > > > [version] 5.0 #50723
> > > >
> > > > pf
> > > >
> > > >> in fact, this is not related to FFI… but it should be fixed…
> > > >>
> > > >> along with the VM version, which version of Pharo are you using?
> > > >>
> > > >> Esteban
> > > >>
> > > >> > On 17 Jun 2016, at 14:04, Max Leske  wrote:
> > > >> >
> > > >> > Hi Petr,
> > > >> >
> > > >> > That looks like a bug with FreeType with our FFI. It should
> > actually have been fixed but I don’t know if the VM for FreeBSD is up to
> > date. Can you post the output of “Smalltalk vm version”?
> > > >> >
> > > >> > Cheers,
> > > >> > Max
> > > >> >
> > > >> >> On 17 Jun 2016, at 13:26, Petr Fischer 
> > wrote:
> > > >> >>
> > > >> >> Hello, I got some random segfaults (while loading Seaside) with 32
> > bit spur vm on FreeBSD - can someone (with low level knowledge) decode
> > attached log?
> > > >> >> Is this some problem with stack size? Can I fix this?
> > > >> >>
> > > >> >> Log:
> > > >> >> http://pastebin.com/raw/NpFUnjh0
> > > >> >>
> > > >> >> There is "**StackOverflow**" lines n the log...
> > > >> >>
> > > >> >> Thanks! pf
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > >
> >
> >

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]

[Petr Fischer]

> On Fri, Jun 17, 2016 at 8:04 PM, Max Leske  wrote:
> > Hi Petr,
> >
> > That looks like a bug with FreeType with our FFI. It should actually have 
> > been fixed but I don’t know if the VM for FreeBSD is up to date. Can you 
> > post the output of “Smalltalk vm version”?
> >
> > Cheers,
> > Max
> >
> 
> Petr,  Based on Max's suggestion, have you tried turning FreeType off?
>World > System > Settings > Apperance > Use Free Type.
> IIUC this will fall back to using built-in Strike Fonts [1], and maybe
> just bypass the issue??

With FreeType off - still segfaulting. I will move this topic (+ how to debug 
this segfaults) to the vm mailinglist.

Thanks!


> 
> [1] 
> http://pharo.gemtalksystems.com/book/LanguageAndLibraries/fonts_in_pharo/strike_fonts/
> 
> P.S. Just curious, in the philosophy of trimming down the Pharo Image
> size, are Strike Fonts a candidate for removal.  It seems like having
> an in-Image fall back is potentially useful when porting to new
> platforms.
> 
> cheers -ben
> 
> 
> >> On 17 Jun 2016, at 13:26, Petr Fischer  wrote:
> >>
> >> Hello, I got some random segfaults (while loading Seaside) with 32 bit 
> >> spur vm on FreeBSD - can someone (with low level knowledge) decode 
> >> attached log?
> >> Is this some problem with stack size? Can I fix this?
> >>
> >> Log:
> >> http://pastebin.com/raw/NpFUnjh0
> >>
> >> There is "**StackOverflow**" lines n the log...
> >>
> >> Thanks! pf
> >>
> >
> >
> 

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

[Petr Fischer]

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
> >> mailto:thierry.goub...@gmail.com>> 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*

[Pharo-dev] RHEL/CentOS vs. libgit2 vs. libcurl-gnutls.so.4 vs. 64bit default VM from pharo.org and repos - report

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello,

Pharo situation on the CentOS/RHEL - major server side Linux distribution:

1) VM installation via this (CentOS7 section via pharo centos repo):
https://pharo.org/gnu-linux-installation-64

Broken. There is no libgit2.so in /usr/lib64/pharo6-vm/
So no git/iceberg, game over (can't load today library dependencies hosted on 
github).

There is probably obsolete VM build in pharo CentOS repository.

2) manual download VM standalone "Pharo 6.1 for GNU/Linux (64bit)" from:
http://pharo.org/download

OK, in this zip package, there is libgit2.so, which has these deps:

...
linux-vdso.so.1 =>  (0x7ffdb0bfe000)
libcurl-gnutls.so.4 => /lib64/libcurl-gnutls.so.4 (0x7fc67dae8000)
libz.so.1 => /lib64/libz.so.1 (0x7fc67d8d2000)
...

But there is no curl-gnutls.so.4 on CentOS7, only libcurl.so.4 (in package 
libcurl).
Result is: no git/iceberg -> game over.

Workaround is:

cd /usr/lib64
ln -s libcurl.so.4 libcurl-gnutls.so.4

--

Solutions:

1) pharo CentOS VM repository needs to be updated (and make the libcurl link in 
the rpm post installation step)
2) PLEASE - add information about linking libcurl-gnutls.so.4 to the CentOS7 
sections (and maybe CentOS6) here:
https://pharo.org/gnu-linux-installation-64

End of report, pf

--- End Message ---

[Pharo-dev] Collection groupedBy: and groups order

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello, I found a useful method in the collection - groupedBy: - the result 
container is some PlugableDictionary (integer variant) and group order (keys) 
is not preserved.

Would not it be better to choose some other Dictionary variant, which preserve 
the order of groups (like in source Collection)?

pf

--- End Message ---

Re: [Pharo-dev] Collection groupedBy: and groups order

[Petr Fischer via Pharo-dev]

--- Begin Message ---
I created two tests, here:

  Gofer it
url: 'https://dev.cvokhaus.cz/st-public/';
package: 'CollectionGroupedByOrderTest';
load.

What do you think?

pf


> Hi Petr 
> 
> do you have a test illustrating what behavior you think should be good?
> 
> Stef
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org 
> 03 59 35 87 52
> Assistant: Julie Jonas 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 

--- End Message ---

Re: [Pharo-dev] Collection groupedBy: and groups order

[Petr Fischer via Pharo-dev]

--- Begin Message ---
I created test case for desired behaviour:

  Gofer it
url: 'https://dev.cvokhaus.cz/st-public/';
package: 'CollectionGroupedByOrderTest';
load.

pf


> Despite the interleavement, the order of the grouped elements as they
> occurred in the original collection could be preserved.
> 
> On Wed, Aug 15, 2018 at 6:34 AM, Damien Pollet  
> wrote:
> > The problem is, there isn't really an order to preserve in the first place,
> > since even if the original collection is a sequencable one, the elements of
> > each group would be interleaved in it. I could see the point of sorting the
> > keys though.
> >
> > On Tue, 14 Aug 2018 at 18:32, Petr Fischer via Pharo-dev
> >  wrote:
> >>
> >> Hello, I found a useful method in the collection - groupedBy: - the result
> >> container is some PlugableDictionary (integer variant) and group order
> >> (keys) is not preserved.
> >>
> >> Would not it be better to choose some other Dictionary variant, which
> >> preserve the order of groups (like in source Collection)?
> >>
> >> pf
> >>
> >
> >
> > --
> > Damien Pollet
> > type less, do more [ | ] http://people.untyped.org/damien.pollet
> 

--- End Message ---

[Pharo-dev] update linux info page again, please [CentOS/RHEL]

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello,

please, edit CentOS7 installation page:
https://pharo.org/gnu-linux-installation-64

and add workaround for CentOS7 section, wihout this symlink, iceberg is broken:

(do as root)
cd /usr/lib64
ln -s libcurl.so.4 libcurl-gnutls.so.4

Best solution is to put this in the RPM post installation step (I mean RPM from 
official Pharo CentOS repository) - but we will wait for this fix for months, 
maybe years, so, workaround info on that page is necessary and easy to manage.

More details here:
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272624.html

Thanks! pf

--- End Message ---

[Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello, I want to propose some small fixes to Pharo, it took me hours just to 
run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)...

Now I am stuck with this Iceberg error:
https://app.box.com/file/321243070589

I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest 
CentOS7) - is Iceberg OK on 64bits?

Thanks! pf

--- End Message ---

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - corrected screenshot link

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Ohh sorry - better screenshot link: 





https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy  





pf


> Hi Petr,
> 
> On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev
>  wrote:
> >
> > Hello, I want to propose some small fixes to Pharo, it took me hours just 
> > to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)...
> >
> > Now I am stuck with this Iceberg error:
> > https://app.box.com/file/321243070589
> 
> I was presented with a login box when I tried to view this.
> 
> 
> > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest 
> > CentOS7) - is Iceberg OK on 64bits?
> 
> Yes, I use it all the time (on Ubuntu 16.04 64 bit).
> 
> Cheers,
> Alistair

--- End Message ---

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

[Petr Fischer via Pharo-dev]

--- Begin Message ---
PharoDebug.log attached 





pf


> Ohh sorry - better screenshot link:   
>   
> 
>   
>   
> 
> https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy
>   
> 
>   
>   
> 
> pf
> 
> 
> > Hi Petr,
> > 
> > On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev
> >  wrote:
> > >
> > > Hello, I want to propose some small fixes to Pharo, it took me hours just 
> > > to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)...
> > >
> > > Now I am stuck with this Iceberg error:
> > > https://app.box.com/file/321243070589
> > 
> > I was presented with a login box when I tried to view this.
> > 
> > 
> > > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and latest 
> > > CentOS7) - is Iceberg OK on 64bits?
> > 
> > Yes, I use it all the time (on Ubuntu 16.04 64 bit).
> > 
> > Cheers,
> > Alistair
> 
THERE_BE_DRAGONS_HERE
PrimitiveFailed: primitive #allocateExecutablePage in FFICallbackThunk class 
failed
23 September 2018 11:37:43.581541 pm

VM: unix - x86_64 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 
29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018
VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: 
Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git

Image: Pharo7.0alpha [Build information: 
Pharo-7.0+alpha.build.1261.sha.9ed1473c3fb9c3853ee730e406bfb012c9fa8297 (64 
Bit)]

FFICallbackThunk class(ProtoObject)>>primitiveFailed:
Receiver: FFICallbackThunk
Arguments and temporary variables: 
selector:   #allocateExecutablePage
Receiver's instance variables: 
superclass: Alien
methodDict: a 
MethodDictionary(#address->FFICallbackThunk>>#address #free->FFIC...etc...
format: 1048576
layout: a ByteLayout
organization:   a ClassOrganization
subclasses: nil
name:   #FFICallbackThunk
classPool:  a Dictionary(#AccessProtect->a Semaphore() 
#AllocatedThunks->an Alie...etc...
sharedPools:an OrderedCollection()
environment:a SystemDictionary(lots of globals)
category:   #'Alien-Core'
lifoCallbackSemaphore:  nil


FFICallbackThunk class(ProtoObject)>>primitiveFailed
Receiver: FFICallbackThunk
Arguments and temporary variables: 

Receiver's instance variables: 
superclass: Alien
methodDict: a 
MethodDictionary(#address->FFICallbackThunk>>#address #free->FFIC...etc...
format: 1048576
layout: a ByteLayout
organization:   a ClassOrganization
subclasses: nil
name:   #FFICallbackThunk
classPool:  a Dictionary(#AccessProtect->a Semaphore() 
#AllocatedThunks->an Alie...etc...
sharedPools:an OrderedCollection()
environment:a SystemDictionary(lots of globals)
category:   #'Alien-Core'
lifoCallbackSemaphore:  nil


FFICallbackThunk class>>allocateExecutablePage
Receiver: FFICallbackThunk
Arguments and temporary variables: 
errorCode:  #'insufficient C memory'
Receiver's ins

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - solved (probably virtualization problem)

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Something very weird happens - my steps:





1) ok, lets run UFFI Tests in Test Runnner  


2) 5 tests fails (RED)  


3) saved the test output to file (button in test runner)


4) quit from Pharo  


5) I forgot to click on the 5 failed tests and generate some PharoDebug.log, 
so... start Pharo again...  
   
6) lets run UFFI Tests again... 


7) bang! all tests OK (GREEN)! WTF? run test again -> all green again (!)   





Bang! Iceberg clone repo works now... I simply can't explain this.  





Whole thing (CentOS7 + Pharo) is inside VirtualBox - most probably the virtual 
image is somehow crippled...
 



Pharo+UFFI+Iceberg is OK, sorry for this mess...





pf


> This looks like an FFI error...
> 
> Can you try running uFFI tests in your system and sen us the results?
> 
> Tx,
> Guille
> 
> On Sun, Sep 23, 2018 at 9:54 PM Petr Fischer via Pharo-dev <
> pharo-dev@lists.pharo.org> wrote:
> 
> > Ohh sorry - better screenshot link:
> >
> >
> >
> > https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy
> >
> >
> >
> > pf
> >
> >
> > > Hi Petr,
> > >
> > > On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev
> > >  wrote:
> > > >
> > > > Hello, I want to propose some small fixes to Pharo, it took me hours
> > just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)...
> > > >
> > > > Now I am stuck with this Iceberg error:
> > > > https://app.box.com/file/321243070589
> > >
> > > I was presented with a login box when I tried to view this.
> > >
> > >
> > > > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and
> > latest CentOS7) - is Iceberg OK on 64bits?
> > >
> > > Yes, I use it all the time (on Ubuntu 16.04 64 bit).
> > >
> > > Cheers,
> > > Alistair
> >
> >
> 
> -- 
> 
> 
> 
> Guille Polito
> 
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> 
> CRIStAL - UMR 9189
> 
> French National Center for Scientific Research - *http://www.cnrs.fr
> <http://www.cnrs.fr>*
> 
> 
> *Web:* *http://guillep.github.io* <http://guillep.github.io>
> 
> *Phone: *+33 06 52 70 66 13

--- End Message ---

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Thanks for your assistance, but sources of this weird behavior is probably in 
the virtualization layer:

http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-September/273069.html

pf

> That means 
> 
> primAllocateExecutablePage
> 
> failed. 
> There should be an errorCode value there, that can help us understand better 
> the problem.
> 
> Can you check at it?
> 
> Thanks!
> 
> Esteban
> 
> > On 24 Sep 2018, at 17:49, Petr Fischer via Pharo-dev 
> >  wrote:
> > 
> >  
> 

--- End Message ---

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

[Petr Fischer via Pharo-dev]

--- Begin Message ---
> Hi Petr,
> 
> along with Esteban’s request for the error code from 
> allocateExecutablePage can you also see whether use of iceberg is successful 
> the second time you launch Pharo?  So start up your virtualbox, try and 
> interact with iceberg, quit if it fails, relaunch and try again?

Yes, after the tests were green (second time, after magic happens), Iceberg was 
also OK - and I mean the whole Iceberg cycle up to creating the Pharo pull 
request right from the Iceberg UI/image.
I recreated whole virtualbox image from scratch and tune some vbox settings - 
described problems have gone and I am not able to recreate the same situation - 
let's forget it, it's not the Pharo thing.

And finally - I see that a lot of work has been done on Iceberg - it's not even 
necessary to leave Pharo for a minute due to the final Github pull request in 
web browser, nice.

pf

> Also in your steps what do you do to prepare?  eg do you boot in virtualbox, 
> return from sleep, or...?
> 
> FYI, allocateExecutablePage uses valloc (IIRC) to get a page from the OS and 
> then uses mprotect to add executable permission to the page before answering 
> the page’s address as the result of the primitive.  The callback machinery 
> then uses the page to provide the executable blue code used in implementing 
> callbacks.  The address of a code sequence in the page is what is actually 
> handed out to C code as a fu croon pointer.  When external code calls this 
> function pointer the code in the sequence invokes a callback into the vm 
> before returning back to C.  Consequently it is key that 
> allocateExecutablePage works correctly.  If it doesn’t then no callbacks.
> 
> _,,,^..^,,,_ (phone)
> 
> > On Sep 24, 2018, at 11:11 AM, Petr Fischer via Pharo-dev 
> >  wrote:
> > 
> > 

--- End Message ---

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello, why is test status of this pull request: FAILURE?

Thanks for clarification, Petr Fischer


> There is a new Pharo build available!
>   
> The status of the build #1271 was: FAILURE.
> 
> The Pull Request #1823 was integrated: 
> "22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary"
> Pull request url: https://github.com/pharo-project/pharo/pull/1823
> 
> Issue Url: https://pharo.fogbugz.com/f/cases/22483
> Build Url: 
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1271/


--- End Message ---

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

[Petr Fischer via Pharo-dev]

--- Begin Message ---
I have that feeling too - critiques pane is annoying + occupying too much place 
- what about showing critiques inline only (in the line nubers and breakpoint 
markers left pane)?

This choice existed for the old Nautilus browser - but I can't find it for 
Calypso.

pf

> I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at the 
> bottom of Calypso browsers in Pharo 7 (dl today), see screenshot:
> 
> 
> Why is that ? I can't resize it to be smaller. 
> On a smaller screen this takes up way too much space.
> Can't we have a widget to remove/collapse that area ? Not a setting.
> 
> Sven
> 

--- End Message ---

[Pharo-dev] PharoLauncher - upgrading to 1.6 on Windows

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello.

I thought I'd try PharoLauncher again after some time and I really have a bad 
luck with this product.

I have a PharoLauncher version 1.5.1 installed. If I run new 1.6 installer, 
this error occurs:

"A more recent version of PharoLauncher is already installed on this computer"
https://app.box.com/s/rbn1n12zvx5rvy4zb1s0fujhkbzwvone

"More recent?..." Really?

I uninstalled old version manually of course, but... PharoLauncher can't update 
itself?

Platform: Windows 10 Pro [1809]

pf

--- End Message ---

[Pharo-dev] [pharo website] add wiki+awesome to the documentation section please

[Petr Fischer via Pharo-dev]

--- Begin Message ---
Hello,

could pharo.org webadmin add this links:

https://github.com/pharo-open-documentation/pharo-wiki
https://github.com/pharo-open-documentation/awesome-pharo

to the documentation section here:
http://pharo.org/documentation

?

Today my colleague asked me about Pharo and I had to find the wiki URL in the 
mailing list archives...

pf

--- End Message ---

Re: [Pharo-dev] [pharo website] add wiki+awesome to the documentation section please

[Petr Fischer via Pharo-dev]

--- Begin Message ---
> I added something to the page, please check.

Perfect!

pf

> 
> > On 12 Feb 2019, at 15:14, Marcus Denker  wrote:
> > 
> > I added
> > 
> > https://github.com/pharo-project/pharo/issues/2501 
> > <https://github.com/pharo-project/pharo/issues/2501>
> > 
> >> On 12 Feb 2019, at 14:44, Petr Fischer via Pharo-dev 
> >>  wrote:
> >> 
> >> 
> >> From: Petr Fischer 
> >> Subject: [pharo website] add wiki+awesome to the documentation section 
> >> please
> >> Date: 12 February 2019 at 14:44:09 CET
> >> To: pharo-dev@lists.pharo.org
> >> 
> >> 
> >> Hello,
> >> 
> >> could pharo.org webadmin add this links:
> >> 
> >> https://github.com/pharo-open-documentation/pharo-wiki
> >> https://github.com/pharo-open-documentation/awesome-pharo
> >> 
> >> to the documentation section here:
> >> http://pharo.org/documentation
> >> 
> >> ?
> >> 
> >> Today my colleague asked me about Pharo and I had to find the wiki URL in 
> >> the mailing list archives...
> >> 
> >> pf
> >> 
> >> 
> >> 
> > 
> 

--- End Message ---