Re: [Pharo-users] Why doesn't the VM command line help show the useful image commands anymore?

[K K Subbu]

On 30/04/19 3:35 AM, Tim Mackinnon wrote:

Anyway - I tried using the command line on OSX ( I noticed they had
used pharo, and not pharo-ui — which I never understood: why is it
not pharo for ui and pharo-cmd for terminal, as it burns most
people?) - and typed “pharo —help”, and you get an impressive long
list of commands - however it doesn’t show you the useful Image
commands anymore? So you would never know to use “pharo Pharo.image
—list”.

A while back it showed you that - but its now gone which seems a
shame?


$ pharo --help

will pass the option --help to the VM, not the virtual image. You have 
to "Precede  by '--' to terminate VM options and begin the 
virtual image and its options.


$ pharo -- --list

will pass the --list to the default image - ${PHARO_IMAGE:-Pharo.image}


I also notice at the bottom of the list, its says the the image name
defaults to Pharo.image - however I haven’t noticed that works at all
- you have to specify an image, so thats a bit misleading.


$ PHARO_IMAGE=Pharo.image ./pharo -- eval 3+4
7
$ PHARO_IMAGE=Pharo.image ./pharo -- --help
Usage: [] [--help] [--copyright] [--version] [--list] [ 
--no-quit ]

--help   print this help message
--copyright  print the copyrights
--versionprint the version for the image and the vm
--list   list a description of all active command line handlers
	--no-quitkeep the image running without activating any other 
command line handler

 a valid subcommand in --list

Preference File Modification:
--preferences-file   load the preferences from the given 
	--no-default-preferencesdo not load any preferences from the 
default locations


Documentation:
A PharoCommandLineHandler handles default command line arguments and 
options.

The PharoCommandLineHandler is activated before all other handlers.
It first checks if another handler is available. If so it will activate 
the found handler.


$ PHARO_IMAGE=Pharo.image ./pharo -- --list
Currently installed Command Line Handlers:
FuelLoads fuel files
config  Install and inspect Metacello Configurations from 
the command line

saveRename the image and changes file
update  Load updates
printVersionPrint image version
st  Loads and executes .st source files
testA command line test runner
clean   Run image cleanup
get Install catalog projects from the command line 
(consult catalog at http://catalog.pharo.org)

evalDirectly evaluates passed in one line scripts

HTH .. Subbu

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[Stephan Eggermont]

TedVanGaalen  wrote:
> Crying victory too soon: 
> Alas, it happened again pharo screen frozen, 
> partly drawn, when going to full screen
> ( see image.)
> frustrating.
> The strange thing however:
>  the Seaside/Zinc server
>  kept running that is: I could enter  and save data in
>  in my test app running in the web browser!
> No idea why.

That is consistent with other reports. Looks like the event loop receiving
keyboard and mouse events gets stopped and not restarted. The http server
runs in its own process

Stephan

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[Ben Coman]

On Tue, 30 Apr 2019 at 17:44, Stephan Eggermont  wrote:
>
> TedVanGaalen  wrote:
> > Crying victory too soon:
> > Alas, it happened again pharo screen frozen,
> > partly drawn, when going to full screen
> > ( see image.)
> > frustrating.
> > The strange thing however:
> >  the Seaside/Zinc server
> >  kept running that is: I could enter  and save data in
> >  in my test app running in the web browser!
> > No idea why.

If you hit  do you see an option for Debug Options > Dump XXX
maybe(?) provide some extra info.

>
> That is consistent with other reports. Looks like the event loop receiving
> keyboard and mouse events gets stopped and not restarted. The http server
> runs in its own process

Its been a long time since I've played with Seaside.
IIUC from Seaside you can get a console-like interface to execute commands(?)
Maybe try...  WorldMorph installNewWorld

Also maybe try commenting out the call to #interCyclePause:.
(btw, your CPU will max out)

cheers -ben

Re: [Pharo-users] Why doesn't the VM command line help show the useful image commands anymore?

[Tim Mackinnon]

Subbu - I didn’t understand your point? How would I know to do pharo -- --list 
, by looking at the output of —help? (And in fact that doesn’t work on OSX, it 
prompts me for an image - thus reinforcing my point that the default image 
doesn’t appear to work, at least not in osx).

I swear a year or two ago, help told you how to do this? As it is now, a new 
user would have no clue - I think it would be helpful if the vm —help suggested 
you try “pharo  —help” for further image based parameters. (And all 
cog users agreed to support —help in images so that this message was true).

Tim

> On 30 Apr 2019, at 09:21, K K Subbu  wrote:
> 
> On 30/04/19 3:35 AM, Tim Mackinnon wrote:
>> Anyway - I tried using the command line on OSX ( I noticed they had
>> used pharo, and not pharo-ui — which I never understood: why is it
>> not pharo for ui and pharo-cmd for terminal, as it burns most
>> people?) - and typed “pharo —help”, and you get an impressive long
>> list of commands - however it doesn’t show you the useful Image
>> commands anymore? So you would never know to use “pharo Pharo.image
>> —list”.
>> A while back it showed you that - but its now gone which seems a
>> shame?
> 
> $ pharo --help
> 
> will pass the option --help to the VM, not the virtual image. You have to 
> "Precede  by '--' to terminate VM options and begin the virtual 
> image and its options.
> 
> $ pharo -- --list
> 
> will pass the --list to the default image - ${PHARO_IMAGE:-Pharo.image}
> 
>> I also notice at the bottom of the list, its says the the image name
>> defaults to Pharo.image - however I haven’t noticed that works at all
>> - you have to specify an image, so thats a bit misleading.
> $ PHARO_IMAGE=Pharo.image ./pharo -- eval 3+4
> 7
> $ PHARO_IMAGE=Pharo.image ./pharo -- --help
> Usage: [] [--help] [--copyright] [--version] [--list] [ --no-quit 
> ]
>   --help   print this help message
>   --copyright  print the copyrights
>   --versionprint the version for the image and the vm
>   --list   list a description of all active command line handlers
>   --no-quitkeep the image running without activating any other 
> command line handler
>a valid subcommand in --list
>   
>   Preference File Modification:
>   --preferences-file   load the preferences from the given 
>   --no-default-preferencesdo not load any preferences from the 
> default locations
>   
> Documentation:
> A PharoCommandLineHandler handles default command line arguments and options.
> The PharoCommandLineHandler is activated before all other handlers.
> It first checks if another handler is available. If so it will activate the 
> found handler.
> 
> $ PHARO_IMAGE=Pharo.image ./pharo -- --list
> Currently installed Command Line Handlers:
>FuelLoads fuel files
>config  Install and inspect Metacello Configurations from the 
> command line
>saveRename the image and changes file
>update  Load updates
>printVersionPrint image version
>st  Loads and executes .st source files
>testA command line test runner
>clean   Run image cleanup
>get Install catalog projects from the command line (consult 
> catalog at http://catalog.pharo.org)
>evalDirectly evaluates passed in one line scripts
> 
> HTH .. Subbu
> 

Re: [Pharo-users] What's wrong with latest Pharo?

[Tim Mackinnon]

Did we ever get the bottom of installing Pharo on linux? I have a user on Arch 
linux who installed pharo from AUR (this is new stuff to me) - and once they 
downloaded an image - they now get an error that looks suspiciously like this 
libgit2 debacle - so I’m wondering what the solution was?

The error is:

External module not found
ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
LGitLibrary>>libgit2_init
FFICalloutAPI>>function:module:
LGitLibrary(Object)>>ffiCall:
LGitLibrary>>libgit2_init
[ self libgit2_init.
self recordInitializationSuccess ] in LGitLibrary>>initializeLibGit2 in Block: 
[ self libgit2_init
BlockClosure>>on:do:

...

> On 4 Apr 2019, at 15:07, Vitor Medina Cruz  wrote:
> 
> No, you can't install libcurl3 with libcurl4. There is a known conflict 
> between them: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1754294 
> , 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900511 
> 
> 
> Ubuntu 18.4 don't come with curl, but I think it comes with libcurl3 (I don't 
> have means to verify it now), but when you install curl, it installs libcurl4 
> and removes libcurl3.
> 
> On Thu, Apr 4, 2019 at 11:00 AM Richard O'Keefe  > wrote:
> apt-cache search
> reports everything it knows about, not just things that are INSTALLED.
> For example, apt-cache search reports lua-curl-dev, but it is not
> installed.
> apt list | grep lua-curl-dev
> 
> The fact that neither libcurl3 nor libcurl4 is initially installed
> means that either of them can be installed without conflict.
> 
> On Thu, 4 Apr 2019 at 01:34, Ben Coman  > wrote:
> 
> On Wed, 3 Apr 2019 at 05:09, Richard O'Keefe  > wrote:
> I just did a complete reinstall of Ubuntu 18.4 on this
> laptop yesterday,
> 
>  
> and it did not come with any version of curl. 
> 
> What do you mean? Under WSL I have installed Ubuntu 18.4 and for...
> $ apt-cache search libcurl | less
> I see libcurl3 and libcurl4
> 
> cheers -ben
>  
> uname -a =>
> Linux Inspiron 4.18.0-16-generic #17~18.04.1-Ubuntu SMP Tue Feb 12 13:35:51 
> UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> 
> On Wed, 3 Apr 2019 at 01:27, Vitor Medina Cruz  > wrote:
> Installing curl don't work because there is a conflict between curl version 
> name used on Ubuntu and that used by Pharo, you can't install libcurl 3 and 
> libcru4 together. Ubuntu 18 comes with libcurl4 and older software depending 
> on libcurl3 broke with it. I tested with minidebian and it also failed. 
> 
> Richard, was you able to use Iceberg? It should only work if either Ubuntu 
> fix this dependency problem with libcurl or Pharo started to use libcrl4.
> 
> 
> 
> On Tue, Apr 2, 2019 at 5:50 AM Richard O'Keefe  > wrote:
> I have Pharo 6.1 and Pharo 7.0 working in Ubuntu 18.04
> with no trouble so far.  I just downloaded the launcher
> from pharo.org  and pulled the images down that way.
> 
> One thing I do find annoying in Ubuntu 18.04 is the
> number of programs (like okular) that spew warning
> messages out the terminal.  Pharo, sadly, is one of
> them.  Whenever a debugger window comes up in Pharo
> there is spewage on the terminal.  But it works.
> 
> 
> On Tue, 2 Apr 2019 at 13:07, john pfersich  > wrote:
> Ubuntu 18.04 LTS is, IMHO, is royal piece of crap. Ubuntu seems to have 
> abandoned programmers tools almost completely in 18.04. I’ve had more 
> problems with support of programming tools in 18.04, more than even Windows. 
> I have run ‘sudo apt install’ maybe 80 times to install tools and libraries. 
> Ubuntu 18.04’s hardware support is also lame compared to 16.04. 
> Personally , I’m not surprised that Pharo doesn’t run on 18.04. I stopped 
> installing 18.04 on my new machines, after all 16.04 still has a few years of 
> support going for it, and at least it works without hours of upgrading. 
> 
> /*—-*/
> Sent from my iPhone
> https://boincstats.com/signature/-1/user/51616339056/sig.png 
> 
> See https://objectnets.net  and 
> https://objectnets.org 
> 
> > On Apr 1, 2019, at 06:06, horrido  > > wrote:
> > 
> > This issue bit me in the ass before, but I forgot. Yes, I had a senior
> > moment.
> > 
> > The issue is this: When I tried to run Pharo under Ubuntu Server 18.04 at
> > OVH last year, it failed. I had to fall back to Ubuntu Server 16.04.
> > 
> > This week, I tried to run Pharo under Ubuntu Server 18.04 at Google Cloud
> > Platform and it failed. Again, I had to fall back to Ubuntu Server 16.04.
> > 
> > Why does this issue

Re: [Pharo-users] What's wrong with latest Pharo?

[Guillermo Polito]

Hi Tim,

Looking at the resolution of the libgit library, I see that in pharo7 the
following:

LGitLibrary >> unixModuleName
| pluginDir |
pluginDir := Smalltalk vm binary parent.
#('libgit2.so' 'libgit2.so.0')
detect: [ :each | (pluginDir / each) exists ]
ifFound: [ :libName | ^ libName ].

self error: 'Module not found.'

That definition may be the root of the problem in linux because it is
returning the unqualified library name without the VM path.
Then, the order of resolution of libraries is the one in the operating
system, which is in your case probably searching in /usr/lib or something
like that.
I'd bet that you have in your system (/usr/lib/something) another libgit
version but probably not matching the expected version in pharo or the
architecture of pharo (32/64 bits).
Thus, pharo finds the library but cannot load it...

If you check in Pharo8, the same method reads slightly different:

LGitLibrary >> unixModuleName
| pluginDir |
pluginDir := Smalltalk vm binary parent.
#('libgit2.so' 'libgit2.so.0')
detect: [ :each | (pluginDir / each) exists ]
ifFound: [ :libName | ^ (pluginDir / libName) fullName ].

self error: 'Module not found.'

Can you check that patching the method like that works in your case?
This maybe deserves a backporting as it may make it super complicated to
work with Iceberg in some linuxes...

On Tue, Apr 30, 2019 at 3:08 PM Tim Mackinnon  wrote:

> Did we ever get the bottom of installing Pharo on linux? I have a user on
> Arch linux who installed pharo from AUR (this is new stuff to me) - and
> once they downloaded an image - they now get an error that looks
> suspiciously like this libgit2 debacle - so I’m wondering what the solution
> was?
>
> The error is:
>
> External module not found
> ExternalLibraryFunction(Object)>>error:
> ExternalLibraryFunction(Object)>>externalCallFailed
> ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
> LGitLibrary>>libgit2_init
> FFICalloutAPI>>function:module:
> LGitLibrary(Object)>>ffiCall:
> LGitLibrary>>libgit2_init
> [ self libgit2_init.
> self recordInitializationSuccess ] in LGitLibrary>>initializeLibGit2 in
> Block: [ self libgit2_init
> BlockClosure>>on:do:
>
> ...
>
> On 4 Apr 2019, at 15:07, Vitor Medina Cruz  wrote:
>
> No, you can't install libcurl3 with libcurl4. There is a known conflict
> between them: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1754294,
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900511
>
> Ubuntu 18.4 don't come with curl, but I think it comes with libcurl3 (I
> don't have means to verify it now), but when you install curl, it installs
> libcurl4 and removes libcurl3.
>
> On Thu, Apr 4, 2019 at 11:00 AM Richard O'Keefe  wrote:
>
>> apt-cache search
>> reports everything it knows about, not just things that are INSTALLED.
>> For example, apt-cache search reports lua-curl-dev, but it is not
>> installed.
>> apt list | grep lua-curl-dev
>>
>> The fact that neither libcurl3 nor libcurl4 is initially installed
>> means that either of them can be installed without conflict.
>>
>> On Thu, 4 Apr 2019 at 01:34, Ben Coman  wrote:
>>
>>>
>>> On Wed, 3 Apr 2019 at 05:09, Richard O'Keefe  wrote:
>>>
 I just did a complete reinstall of Ubuntu 18.4 on this
 laptop yesterday,

>>>
>>>
>>>
 and it did not come with any version of curl.

>>>
>>> What do you mean? Under WSL I have installed Ubuntu 18.4 and for...
>>> $ apt-cache search libcurl | less
>>> I see libcurl3 and libcurl4
>>>
>>> cheers -ben
>>>
>>>
 uname -a =>
 Linux Inspiron 4.18.0-16-generic #17~18.04.1-Ubuntu SMP Tue Feb 12
 13:35:51 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux



 On Wed, 3 Apr 2019 at 01:27, Vitor Medina Cruz 
 wrote:

> Installing curl don't work because there is a conflict between curl
> version name used on Ubuntu and that used by Pharo, you can't install
> libcurl 3 and libcru4 together. Ubuntu 18 comes with libcurl4 and older
> software depending on libcurl3 broke with it. I tested with minidebian and
> it also failed.
>
> Richard, was you able to use Iceberg? It should only work if either
> Ubuntu fix this dependency problem with libcurl or Pharo started to use
> libcrl4.
>
>
>
> On Tue, Apr 2, 2019 at 5:50 AM Richard O'Keefe 
> wrote:
>
>> I have Pharo 6.1 and Pharo 7.0 working in Ubuntu 18.04
>> with no trouble so far.  I just downloaded the launcher
>> from pharo.org and pulled the images down that way.
>>
>> One thing I do find annoying in Ubuntu 18.04 is the
>> number of programs (like okular) that spew warning
>> messages out the terminal.  Pharo, sadly, is one of
>> them.  Whenever a debugger window comes up in Pharo
>> there is spewage on the terminal.  But it works.
>>
>>
>> On Tue, 2 Apr 2019 at 13:07, john pfersich 
>> wrote:
>>
>>> Ubuntu 18.04 LTS is, IMHO, is royal piece of crap. Ubuntu seems to
>>> have abandone

Re: [Pharo-users] What's wrong with latest Pharo?

[Tim Mackinnon]

Hi Guille - I’m not using Arch Linux myself - this was a seasoned exercism 
contributor trying to give pharo a spin - and sadly it hasn’t gone well (shame 
as they might have been an advocate) They also commented:

"I'm not quite sure though if I really want to continue from here. As someone 
new to pharo, I basically can't find any installation instructions that go 
beyond that evil `curl`. I'm happy to play this to the end with you, that at 
least exercism gets proper instructions, but the pharo community really should 
change their mind and provide more and better documentation about systemwide 
installation and packages. I have a hard time seeing something used at my 
compnay that does not provide an RPM out of the box…”

Which is fair play.

However I did get some details which might salvage something (and maybe they 
can try)

Its ArchLinux (apparently there are no versions in Arch, its always the latest).
Pharo wa installed via AUR (looks like a bit old - 2019-01-24 18:18) - not sure 
that is the issue though
AUR does give an image so they downloaded the latest 64 bit one from here - 
https://files.pharo.org/image/70/
Libgit2 was missing - that was installed (not clear on how - could ask)

After all of this - it did launch - they saw a welcome screen then it crashed 
(I think they were doing our eval string to metacello load exercism - so it 
would then use libgit2)

They then got this error:
https://pastebin.com/W2D86ZS4

I’ve pasted the error below - for prosperity.

Tim

Pharo VM version: 5.0-201901231209  Wed Jan 23 12:32:13 UTC 2019 gcc 4.8 
[Production Spur 64-bit VM]
Built from: CoInterpreter VMMaker.oscog-eem.2509 uuid: 
91e81f64-95de-4914-a960-8f842be3a194 Jan 23 2019
With: StackToRegisterMappingCogit VMMaker.oscog-eem.2509 uuid: 
91e81f64-95de-4914-a960-8f842be3a194 Jan 23 2019
Revision: VM: 201901231209 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed Jan 23 07:09:49 
2019 CommitHash: a4b2dfa6 Plugins: 201901231209 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git
Build host: Linux travis-job-3a8f8935-e791-48da-aa41-2eccc2452870 
4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 
x86_64 x86_64 GNU/Linux
plugin path: /opt/pharo/bin [default: /opt/pharo/lib/pharo/5.0-201901231209/]


C stack backtrace & registers:
rax 0x rbx 0x7f4aacbce700 rcx 0x rdx 0x0014
rdi 0x rsi 0x rbp 0x rsp 0x7fffdc831d00
r8  0x r9  0x7f4aacbbce22 r10 0x0006 r11 0x7fffdc831d08
r12 0x0040 r13 0x0014 r14 0x r15 0x7f4aacbbce22
rip 0x7f4aac72f3b9
*/lib/libcrypto.so.1.1(BN_num_bits+0x9)[0x7f4aac72f3b9]
/opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x41b0d3]
/opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x41cb2e]
/lib/libpthread.so.0(+0x124d0)[0x7f4aaeb2d4d0]
/lib/libcrypto.so.1.1(BN_num_bits+0x9)[0x7f4aac72f3b9]
/lib/libcrypto.so.1.1(RSA_size+0xe)[0x7f4aac81fa5e]
/lib/libcrypto.so.1.1(+0x1b43b6)[0x7f4aac8273b6]
/lib/libcrypto.so.1.1(RSA_verify+0x2b)[0x7f4aac82777b]
/opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0x2c2df)[0x7f4aac4672df]
/opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0xabbf)[0x7f4aac445bbf]
/opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0xe377)[0x7f4aac449377]
/opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0xffbe)[0x7f4aac44afbe]
/opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0x11cb6)[0x7f4aac44ccb6]
/opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0x1ad00)[0x7f4aac455d00]
/opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(libssh2_session_handshake+0x2e)[0x7f4aac455f8f]
/lib/libgit2.so(+0xc3265)[0x7f4aacb33265]
/lib/libgit2.so(+0xbf06b)[0x7f4aacb2f06b]
/lib/libgit2.so(git_remote_connect+0x166)[0x7f4aacb0bf66]
/lib/libgit2.so(git_remote_fetch+0x97)[0x7f4aacb0d417]
/lib/libgit2.so(git_clone+0x36a)[0x7f4aaca9c4ea]
/opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x4cacb6]
/opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x4585f7]
/opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x45a667]
/opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo(ceSendsupertonumArgs+0x265)[0x45c4b5]
[0x1f00100]
[0x7f4aacbcc7b0]


Smalltalk stack dump:
0x7fffdc85b750 M LGitRepository>clone:url:local_path:options: 0x246e7f0: 
a(n) LGitRepository
0x7fffdc85b7d0 I FFICalloutAPI>function:module: 0x25189e8: a(n) 
FFICalloutAPI
0x7fffdc85b820 I LGitRepository(LGitExternalObject)>callUnchecked:options: 
0x246e7f0: a(n) LGitRepository
0x7fffdc85b870 I LGitRepository>clone:url:local_path:options: 0x246e7f0: 
a(n) LGitRepository
0x7fffdc85b8e8 I [] in LGitRepository>clone:options:to: 0x246e7f0: a(n) 
LGitRepository
0x7fffdc85b928 I LGitRepository(LGitExternalObject)>withReturnHandlerDo: 
0x246e7f0: a(n) LGitRepository
0x7fffdc85b970 I LGitRepository>clone:options:to: 0x246e7f0: a(n) 
LGitRepository
0x7fffdc85b9c8 I LGitRepository>clone:options: 0x246e7f0: a(n) 
LGitRepository
0x7fffdc85ba10 M [] in IceGitClo

Re: [Pharo-users] What's wrong with latest Pharo?

[Tim Mackinnon]

Actually - the user has confirmed a bit more (which sounds like your hunch 
Guille):

Hmm… Just loading the image without `eval`ing something seems to boot up well. 
But then I also realise, that there is a warning:

```ioLoadModule(/opt/pharo/bin/../lib/pharo/5.0-201901231209/libgit2.so):
  libcurl-gnutls.so.4: cannot open shared object file: No such file or 
directory```
(edited)

So this looks like pharo tries to load a bundled libgit2 first during bootup 
which fails and only later, when trying to call into it, system resolves into 
the system installed one.
Which then causes the segfault for some reason.

I’ll see if I can guide him through changing that method.

Tim

> On 30 Apr 2019, at 15:53, Tim Mackinnon  wrote:
> 
> Hi Guille - I’m not using Arch Linux myself - this was a seasoned exercism 
> contributor trying to give pharo a spin - and sadly it hasn’t gone well 
> (shame as they might have been an advocate) They also commented:
> 
> "I'm not quite sure though if I really want to continue from here. As someone 
> new to pharo, I basically can't find any installation instructions that go 
> beyond that evil `curl`. I'm happy to play this to the end with you, that at 
> least exercism gets proper instructions, but the pharo community really 
> should change their mind and provide more and better documentation about 
> systemwide installation and packages. I have a hard time seeing something 
> used at my compnay that does not provide an RPM out of the box…”
> 
> Which is fair play.
> 
> However I did get some details which might salvage something (and maybe they 
> can try)
> 
> Its ArchLinux (apparently there are no versions in Arch, its always the 
> latest).
> Pharo wa installed via AUR (looks like a bit old - 2019-01-24 18:18) - not 
> sure that is the issue though
> AUR does give an image so they downloaded the latest 64 bit one from here - 
> https://files.pharo.org/image/70/ 
> Libgit2 was missing - that was installed (not clear on how - could ask)
> 
> After all of this - it did launch - they saw a welcome screen then it crashed 
> (I think they were doing our eval string to metacello load exercism - so it 
> would then use libgit2)
> 
> They then got this error:
> https://pastebin.com/W2D86ZS4 
> 
> I’ve pasted the error below - for prosperity.
> 
> Tim
> 
> Pharo VM version: 5.0-201901231209  Wed Jan 23 12:32:13 UTC 2019 gcc 4.8 
> [Production Spur 64-bit VM]
> Built from: CoInterpreter VMMaker.oscog-eem.2509 uuid: 
> 91e81f64-95de-4914-a960-8f842be3a194 Jan 23 2019
> With: StackToRegisterMappingCogit VMMaker.oscog-eem.2509 uuid: 
> 91e81f64-95de-4914-a960-8f842be3a194 Jan 23 2019
> Revision: VM: 201901231209 
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>  Date: Wed Jan 23 
> 07:09:49 2019 CommitHash: a4b2dfa6 Plugins: 201901231209 
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
> 
> Build host: Linux travis-job-3a8f8935-e791-48da-aa41-2eccc2452870 
> 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 
> x86_64 x86_64 GNU/Linux
> plugin path: /opt/pharo/bin [default: /opt/pharo/lib/pharo/5.0-201901231209/]
> 
> 
> C stack backtrace & registers:
>   rax 0x rbx 0x7f4aacbce700 rcx 0x rdx 0x0014
>   rdi 0x rsi 0x rbp 0x rsp 0x7fffdc831d00
>   r8  0x r9  0x7f4aacbbce22 r10 0x0006 r11 0x7fffdc831d08
>   r12 0x0040 r13 0x0014 r14 0x r15 0x7f4aacbbce22
>   rip 0x7f4aac72f3b9
> */lib/libcrypto.so.1.1(BN_num_bits+0x9)[0x7f4aac72f3b9]
> /opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x41b0d3]
> /opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x41cb2e]
> /lib/libpthread.so.0(+0x124d0)[0x7f4aaeb2d4d0]
> /lib/libcrypto.so.1.1(BN_num_bits+0x9)[0x7f4aac72f3b9]
> /lib/libcrypto.so.1.1(RSA_size+0xe)[0x7f4aac81fa5e]
> /lib/libcrypto.so.1.1(+0x1b43b6)[0x7f4aac8273b6]
> /lib/libcrypto.so.1.1(RSA_verify+0x2b)[0x7f4aac82777b]
> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0x2c2df)[0x7f4aac4672df]
> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0xabbf)[0x7f4aac445bbf]
> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0xe377)[0x7f4aac449377]
> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0xffbe)[0x7f4aac44afbe]
> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0x11cb6)[0x7f4aac44ccb6]
> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0x1ad00)[0x7f4aac455d00]
> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(libssh2_session_handshake+0x2e)[0x7f4aac455f8f]
> /lib/libgit2.so(+0xc3265)[0x7f4aacb33265]
> /lib/libgit2.so(+0xbf06b)[0x7f4aacb2f06b]
> /lib/libgit2.so(git_remote_connect+0x166)[0x7f4aacb0bf66]
> /lib/libgit2.so(git_remote_fetch+0x97)[0x7f4aacb0d417]
> /lib/libgit2.so(git_clone+0x36a)[0x7f4aaca9c4ea]
> /opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[

[Pharo-users] Right clicking often fails first time?

[Tim Mackinnon]

This has been bugging me for a long time - but its incredibly annoying that 
when you right click on a class, package, Iceberg entry - that the context menu 
doesn’t often appear. You have to click again (or remember to click first and 
then right click - even if the reverent item is already highlighted).

Why is this? Is it a bug worth reporting and seeing if it can be fixed (or is 
it just me? This is in 703, OSX High Sierra)

Tim

Re: [Pharo-users] What's wrong with latest Pharo?

[Tim Mackinnon]

Guille - it looks like modifying that method and :
"I installed some other package (`libcurl-gnutls`) which is an "addon" to the 
regular `libcurl`.”

Got us further - now he’s getting IceAuthenticationError- which could be down 
to git vs https. (I can use the #remoteTypeSelector: trick to hopefully fix 
that).

When I confirm everything, I will report back the magic syntax (at least for 
Arch) - as well as the desire to back port that fix to 7.

Thanks for chipping in (and this is the thread that keeps on giving…)

Tim

> On 30 Apr 2019, at 16:08, Tim Mackinnon  wrote:
> 
> Actually - the user has confirmed a bit more (which sounds like your hunch 
> Guille):
> 
> Hmm… Just loading the image without `eval`ing something seems to boot up 
> well. But then I also realise, that there is a warning:
> 
> ```ioLoadModule(/opt/pharo/bin/../lib/pharo/5.0-201901231209/libgit2.so):
>   libcurl-gnutls.so.4: cannot open shared object file: No such file or 
> directory```
> (edited)
> 
> So this looks like pharo tries to load a bundled libgit2 first during bootup 
> which fails and only later, when trying to call into it, system resolves into 
> the system installed one.
> Which then causes the segfault for some reason.
> 
> I’ll see if I can guide him through changing that method.
> 
> Tim
> 
>> On 30 Apr 2019, at 15:53, Tim Mackinnon > > wrote:
>> 
>> Hi Guille - I’m not using Arch Linux myself - this was a seasoned exercism 
>> contributor trying to give pharo a spin - and sadly it hasn’t gone well 
>> (shame as they might have been an advocate) They also commented:
>> 
>> "I'm not quite sure though if I really want to continue from here. As 
>> someone new to pharo, I basically can't find any installation instructions 
>> that go beyond that evil `curl`. I'm happy to play this to the end with you, 
>> that at least exercism gets proper instructions, but the pharo community 
>> really should change their mind and provide more and better documentation 
>> about systemwide installation and packages. I have a hard time seeing 
>> something used at my compnay that does not provide an RPM out of the box…”
>> 
>> Which is fair play.
>> 
>> However I did get some details which might salvage something (and maybe they 
>> can try)
>> 
>> Its ArchLinux (apparently there are no versions in Arch, its always the 
>> latest).
>> Pharo wa installed via AUR (looks like a bit old - 2019-01-24 18:18) - not 
>> sure that is the issue though
>> AUR does give an image so they downloaded the latest 64 bit one from here - 
>> https://files.pharo.org/image/70/ 
>> Libgit2 was missing - that was installed (not clear on how - could ask)
>> 
>> After all of this - it did launch - they saw a welcome screen then it 
>> crashed (I think they were doing our eval string to metacello load exercism 
>> - so it would then use libgit2)
>> 
>> They then got this error:
>> https://pastebin.com/W2D86ZS4 
>> 
>> I’ve pasted the error below - for prosperity.
>> 
>> Tim
>> 
>> Pharo VM version: 5.0-201901231209  Wed Jan 23 12:32:13 UTC 2019 gcc 4.8 
>> [Production Spur 64-bit VM]
>> Built from: CoInterpreter VMMaker.oscog-eem.2509 uuid: 
>> 91e81f64-95de-4914-a960-8f842be3a194 Jan 23 2019
>> With: StackToRegisterMappingCogit VMMaker.oscog-eem.2509 uuid: 
>> 91e81f64-95de-4914-a960-8f842be3a194 Jan 23 2019
>> Revision: VM: 201901231209 
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>>  Date: Wed Jan 23 
>> 07:09:49 2019 CommitHash: a4b2dfa6 Plugins: 201901231209 
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>> 
>> Build host: Linux travis-job-3a8f8935-e791-48da-aa41-2eccc2452870 
>> 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 
>> x86_64 x86_64 x86_64 GNU/Linux
>> plugin path: /opt/pharo/bin [default: /opt/pharo/lib/pharo/5.0-201901231209/]
>> 
>> 
>> C stack backtrace & registers:
>>  rax 0x rbx 0x7f4aacbce700 rcx 0x rdx 0x0014
>>  rdi 0x rsi 0x rbp 0x rsp 0x7fffdc831d00
>>  r8  0x r9  0x7f4aacbbce22 r10 0x0006 r11 0x7fffdc831d08
>>  r12 0x0040 r13 0x0014 r14 0x r15 0x7f4aacbbce22
>>  rip 0x7f4aac72f3b9
>> */lib/libcrypto.so.1.1(BN_num_bits+0x9)[0x7f4aac72f3b9]
>> /opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x41b0d3]
>> /opt/pharo/bin/../lib/pharo/5.0-201901231209/pharo[0x41cb2e]
>> /lib/libpthread.so.0(+0x124d0)[0x7f4aaeb2d4d0]
>> /lib/libcrypto.so.1.1(BN_num_bits+0x9)[0x7f4aac72f3b9]
>> /lib/libcrypto.so.1.1(RSA_size+0xe)[0x7f4aac81fa5e]
>> /lib/libcrypto.so.1.1(+0x1b43b6)[0x7f4aac8273b6]
>> /lib/libcrypto.so.1.1(RSA_verify+0x2b)[0x7f4aac82777b]
>> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0x2c2df)[0x7f4aac4672df]
>> /opt/pharo/lib/pharo/5.0-201901231209/libssh2.so.1(+0xabbf)[0x7f4aac445bbf]
>> /opt/

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

[TedVanGaalen]

Thanks, but I will revert to Pharo 5.0 (pre spur VM)  again...
until the problems with 7.x are solved... or 8 is really stable.

I was regularly telling colleagues with whom I converse on Twitter
(e.g. Swift, C# and other programmers) 
that they should try Smalltalk, especially Pharo,
to see for themselves that programming in Smalltalk 
has many advantages, which however only become 
obvious when actually using Smalltalk. 
So I wrote tweets like
"try it for a week, and you'll be hooked" etc.
So people perhaps downloaded Pharo, but then
to get frozen in a mere minute..

if the *first experience* of those new to Smalltalk
is a freezing Pharo immediately after going full screen
or moving the window.
they might (probably will) think 
"ok, agreed, nothing is perfect, but so much for Smalltalk then, wasting my
time" 
never to return to Smalltalk again.  
Of course, that's really not good at all.

How can one promote Smalltalk if this kind of things happen?
Please note that this is not meant as a negative comment,
because I know that there are not many people
working on Pharo, but those that do, do the best they can!
However, it is unfortunately the status quo.
Very bad, because it bounces away those
who would really like to try Pharo
and might become enthusiastic Smalltalkers.

"Under the hood", need to know? 

New users know nearly nothing about VMs and how they
work. They shouldn't have to.
Let alone hacking VMs etc. to get Pharo going.
(respect btw for those building VMs, this is
not trivial, but this is exactly the reason why it is not a "user thing")

(I am profiling myself here as a typical Smalltalk
user, application programmer. 
Not a tool builder, I know almost nothing about VMs
(Do I have to?) and the deepest system related classes
in the Smalltalk deep sea. Initially, I live on the surface, and
only dive deeper when needed, so to speak.
e.g. looking for base classes like Morph.
If I go deeper, I might run out of mental oxygen :o) 
It is nearly impossible to know all classes living
in a Smalltalk image. (Seems this ocean metaphor is a 
nice one, we know more about (the surface of) the moon
 than about what is in the the depths of our oceans :o) )

All they (should care about) is learning/using
Smalltalk from an application programmer's perspective.

Perhaps it might be a good idea
to make it clear on the Pharo website
that version 5.0 (non spur VM) is the most recent stable version.
when using Pharo for safe reliable application building.
Focus on stable releases, add new things only after that.
(this might sound not too academic, 
but down-to-earth industrial, and yes it is) 

AndPlease   Keep   It  Simple: 
just a no frills one-click-image will do.
no hassle with launchers, loaders etc. 
For example you can still download
Blender (www.blender.org)
A large 3d application in a zip file
which is a single complete app directory with everything in it.

Thanks
TedvG






Ben Coman wrote
> On Tue, 30 Apr 2019 at 17:44, Stephan Eggermont <

> stephan@

> > wrote:
>>
>> TedVanGaalen <

> tedvga@

> > wrote:
>> > Crying victory too soon:
>> > Alas, it happened again pharo screen frozen,
>> > partly drawn, when going to full screen
>> > ( see image.)
>> > frustrating.
>> > The strange thing however:
>> >  the Seaside/Zinc server
>> >  kept running that is: I could enter  and save data in
>> >  in my test app running in the web browser!
>> > No idea why.
> 
> If you hit 
> 
>  do you see an option for Debug Options > Dump XXX
> maybe(?) provide some extra info.
> 
>>
>> That is consistent with other reports. Looks like the event loop
>> receiving
>> keyboard and mouse events gets stopped and not restarted. The http server
>> runs in its own process
> 
> Its been a long time since I've played with Seaside.
> IIUC from Seaside you can get a console-like interface to execute
> commands(?)
> Maybe try...  WorldMorph installNewWorld
> 
> Also maybe try commenting out the call to #interCyclePause:.
> (btw, your CPU will max out)
> 
> cheers -ben





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] What's wrong with latest Pharo?

[Tim Mackinnon]

Oh well - even after modifying that method and trying the remoteTypeSelector: 
trick it insists on giving the iceAuthenticationError - so maybe the libcurl2 
install didn’t work (he said he had to install "libcurl-gnutls” to get that 
far).

Interestingly - my osx setup has suddenly starting giving me an 
IceAuthenticationError in a fresh image (I can’t imagine its related is it? 
Could that repo suddenly have some issue? I had the same error yesterday and 
had to clear out the iceberg-local). It seems that iceberg is still not quite 
as rock solid as we would like.

Tim

> On 30 Apr 2019, at 17:15, Tim Mackinnon  wrote:
> 
> Guille - it looks like modifying that method and :
> "I installed some other package (`libcurl-gnutls`) which is an "addon" to the 
> regular `libcurl`.”
> 
> Got us further - now he’s getting IceAuthenticationError- which could be down 
> to git vs https. (I can use the #remoteTypeSelector: trick to hopefully fix 
> that).
> 
> When I confirm everything, I will report back the magic syntax (at least for 
> Arch) - as well as the desire to back port that fix to 7.
> 
> Thanks for chipping in (and this is the thread that keeps on giving…)
> 
> Tim
> 
>> On 30 Apr 2019, at 16:08, Tim Mackinnon > > wrote:
>> 
>> Actually - the user has confirmed a bit more (which sounds like your hunch 
>> Guille):
>> 
>> Hmm… Just loading the image without `eval`ing something seems to boot up 
>> well. But then I also realise, that there is a warning:
>> 
>> ```ioLoadModule(/opt/pharo/bin/../lib/pharo/5.0-201901231209/libgit2.so):
>>   libcurl-gnutls.so.4: cannot open shared object file: No such file or 
>> directory```
>> (edited)
>> 
>> So this looks like pharo tries to load a bundled libgit2 first during bootup 
>> which fails and only later, when trying to call into it, system resolves 
>> into the system installed one.
>> Which then causes the segfault for some reason.
>> 
>> I’ll see if I can guide him through changing that method.
>> 
>> Tim
>> 
>>> On 30 Apr 2019, at 15:53, Tim Mackinnon >> > wrote:
>>> 
>>> Hi Guille - I’m not using Arch Linux myself - this was a seasoned exercism 
>>> contributor trying to give pharo a spin - and sadly it hasn’t gone well 
>>> (shame as they might have been an advocate) They also commented:
>>> 
>>> "I'm not quite sure though if I really want to continue from here. As 
>>> someone new to pharo, I basically can't find any installation instructions 
>>> that go beyond that evil `curl`. I'm happy to play this to the end with 
>>> you, that at least exercism gets proper instructions, but the pharo 
>>> community really should change their mind and provide more and better 
>>> documentation about systemwide installation and packages. I have a hard 
>>> time seeing something used at my compnay that does not provide an RPM out 
>>> of the box…”
>>> 
>>> Which is fair play.
>>> 
>>> However I did get some details which might salvage something (and maybe 
>>> they can try)
>>> 
>>> Its ArchLinux (apparently there are no versions in Arch, its always the 
>>> latest).
>>> Pharo wa installed via AUR (looks like a bit old - 2019-01-24 18:18) - not 
>>> sure that is the issue though
>>> AUR does give an image so they downloaded the latest 64 bit one from here - 
>>> https://files.pharo.org/image/70/ 
>>> Libgit2 was missing - that was installed (not clear on how - could ask)
>>> 
>>> After all of this - it did launch - they saw a welcome screen then it 
>>> crashed (I think they were doing our eval string to metacello load exercism 
>>> - so it would then use libgit2)
>>> 
>>> They then got this error:
>>> https://pastebin.com/W2D86ZS4 
>>> 
>>> I’ve pasted the error below - for prosperity.
>>> 
>>> Tim
>>> 
>>> Pharo VM version: 5.0-201901231209  Wed Jan 23 12:32:13 UTC 2019 gcc 4.8 
>>> [Production Spur 64-bit VM]
>>> Built from: CoInterpreter VMMaker.oscog-eem.2509 uuid: 
>>> 91e81f64-95de-4914-a960-8f842be3a194 Jan 23 2019
>>> With: StackToRegisterMappingCogit VMMaker.oscog-eem.2509 uuid: 
>>> 91e81f64-95de-4914-a960-8f842be3a194 Jan 23 2019
>>> Revision: VM: 201901231209 
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>>>  Date: Wed Jan 23 
>>> 07:09:49 2019 CommitHash: a4b2dfa6 Plugins: 201901231209 
>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git 
>>> 
>>> Build host: Linux travis-job-3a8f8935-e791-48da-aa41-2eccc2452870 
>>> 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 
>>> x86_64 x86_64 x86_64 GNU/Linux
>>> plugin path: /opt/pharo/bin [default: 
>>> /opt/pharo/lib/pharo/5.0-201901231209/]
>>> 
>>> 
>>> C stack backtrace & registers:
>>> rax 0x rbx 0x7f4aacbce700 rcx 0x rdx 0x0014
>>> rdi 0x rsi 0x rbp 0x rsp 0x7fffdc831d00
>>> r8  0x

Re: [Pharo-users] Runaway scrolling in Pharo 7 on Ubuntu 18.04

[Pierce Ng]

On Sun, Apr 28, 2019 at 10:02:35AM -0500, Brainstorms wrote:
> I tried this in a Linux container on a Chromebook (a Pixelbook model), and
> got the same behavior for both the Glamour Example Browser and when
> scrolling long methods in the code browser.
> 
> The Linux version in the default ChromeOS container is Debian 9 (stretch).

So not just me. Thanks.

Re: [Pharo-users] Why doesn't the VM command line help show the useful image commands anymore?

[K K Subbu]

On 30/04/19 6:14 PM, Tim Mackinnon wrote:

Subbu - I didn’t understand your point? How would I know to do pharo
-- --list , by looking at the output of —help? (And in fact that
doesn’t work on OSX, it prompts me for an image - thus reinforcing my
point that the default image doesn’t appear to work, at least not in
osx).


Tim, I don't have access to Mac OSX :-(.

The usage text is printed in lines 296-301 in

https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/platforms/Mac%20OS/vm/sqMacUnixCommandLineInterface.c

If you don't see the same usage message, then it is a bug, possibly a 
missing macro def in the build script.


The platform startup code on Mac and Linux are similar. They both parse 
args for option words starting with single or double hyphens until a 
word which matches "*.image" or "--" is seen. Rest of the words are 
treated as a image (optional) and its arguments.


Regards .. Subbu