Re: [Pharo-users] [ANN] Iceberg v1.0.0

[Esteban Lorenzano]

hi,

> On 30 May 2018, at 01:59, Andrei Stebakov  wrote:
> 
> On Pharo 7.0, Windows 10 when I try to clone from pillar-markup/pillar on 
> Windows 10, it gives me an error "the filename or extension is too long”

this is more a problem of pillar being in filetree format than iceberg.
there is no clear way to fix that other than migrate to tonel.

but you can try to get smaller paths, like putting your sources in C:\pillar

> Also I got a couple of questions:
> - How do I check the version of Iceberg

not much way this days, since iceberg is installed outside iceberg.

> - How can I update from Iceberg 0.7.1 on Pharo 6.1 (installed using 
> instructions from https://github.com/pharo-vcs/iceberg 
> ) to latest Iceberg 1.0.1?

The instructions there are titled “updating iceberg” and “for Pharo 6.1” so yes 
:)
the only difference is you have to change “0.7.?” with “1.0.?” (I need to 
update that).

Esteban

> 
> Thanks!
> Andrei
> 
> On Tue, May 29, 2018 at 5:30 AM, Guillermo Polito  > wrote:
> Hi all,
> 
> Time for a new Iceberg update, that will be available in the next Pharo 
> build. This time, there are lots of cleanups and enhancements. On the big 
> highlights:
> 
> - Tonel migration plugin is available in the "Other menu item"
> - Tests are green on 64 bits! (meaning iceberg can be safely used in 64 bits).
> 
> Thanks to everybody that participated in reviewing, opening/closing issues or 
> even fixing a typo!
> 
> # Documentation
> 
> Just as a reminder, here you have a link to iceberg's wiki, convering some 
> info like terminology, how to help us, and so on...
> 
> https://github.com/pharo-vcs/iceberg/wiki 
> 
> 
> # And some videos ;)
> 
> - Branching and merging https://www.youtube.com/watch?v=DBzkjwABPEI 
> 
> - Loading a Baseline https://youtu.be/brUHEOr-p_E 
> 
> - Contributing to Iceberg https://youtu.be/yGr5HvVWM0M 
> 
> 
> # Changes Log
> 
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.0.0 
> 
> 
> Enjoy, Guille
> 
> PS, detailed changes log below:
> 
> # Cleanups
> 
> #819 Fix tooltip typo in settings 
> #800 Iceberg should be removed from the catalogue
> #801 Remove not referenced packages 
> #803 Correct some lints in tests
> #806 Bad repair options when local repository is missing
> #725 Remove and clean old UI
> #794 Some classes should use category "utilities" instead of "utility"
> #791 Begin to remove old UI
> #734 Begin to remove old UI
> #576 Add link to github/gitlab ssh instructions
> 
> # Enhancements
> 
> #776 Upgrade to Commander 0.6.2  dependencies
> #765 Add command to copy SHA from history window
> #793 Add the commit message to history window
> #785 Metacello conflicts are not handled Metacello Integration
> 
> # Bug fixes
> 
> #771 IceTipRemoveFromRepositoryPackageCommand >> execute is not implemented
> #748 Code subdirectory in empty repository
> #767 Error while pulling with renamed packages
> #814 Moving extension from a package removes extended class
> #807 When we do not have the right to push on a report we get an Error 
> instead of the pop up!
> #768 Inverse merge preview shows wrong diff
> #784 Pulling from a non existing remote branch fails#810 #removePackage: 
> should recursively delete files
> 
> # Documentation
> 
> #702 Create screencast - How to contribute to iceberg
> #774 Copy Wiki contribution page to pharo-project/pharo wiki
> 
> # Infrastructure
> 
> #761 Make tests run in 64 bits Pharo 7
> 
> 

Re: [Pharo-users] Lazy vs eager initialization

[Ben Coman]

While protoyping in a "live" system like Pharo, you often may add a new
instance variable to existing object,
the value of which is "nil" and may break the associated behaviour you next
add.
To deal with that you either have to sprinkle ifNils: around your code,
or alternatively do it in one location with lazy initialization.

So in general, lazy initialization is good for prototyping.
Once you're past prototyping there might be some advantage to refactoring
away from lazy initialization.

cheers -ben




On 29 May 2018 at 23:49, sergio ruiz  wrote:

> If a model has a list of things.. such as a user that can/may have lots of
> pets, are there any real benefits to initializing the list of pets lazily?
>
> like:
>
> self pets := OrderedCollection new.
>
> vs.
>
> pets
>  pets ifNil: [self pets: OrderedCollection new]
>  ^ pets
>
> thanks!
>
> 
> peace,
> sergio
> photographer, journalist, visionary
>
> Public Key: http://bit.ly/29z9fG0
> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
> http://www.codeandmusic.com
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101
>

Re: [Pharo-users] [ANN] Iceberg v1.0.0

[Andrei Stebakov]

On Pharo 7.0, Windows 10 when I try to clone from pillar-markup/pillar on
Windows 10, it gives me an error "the filename or extension is too long"
Also I got a couple of questions:
- How do I check the version of Iceberg
- How can I update from Iceberg 0.7.1 on Pharo 6.1 (installed using
instructions from https://github.com/pharo-vcs/iceberg) to latest Iceberg
1.0.1?

Thanks!
Andrei

On Tue, May 29, 2018 at 5:30 AM, Guillermo Polito  wrote:

> Hi all,
>
> Time for a new Iceberg update, that will be available in the next Pharo
> build. This time, there are lots of cleanups and enhancements. On the big
> highlights:
>
> - Tonel migration plugin is available in the "Other menu item"
> - Tests are green on 64 bits! (meaning iceberg can be safely used in 64
> bits).
>
> Thanks to everybody that participated in reviewing, opening/closing issues
> or even fixing a typo!
>
> # Documentation
>
> Just as a reminder, here you have a link to iceberg's wiki, convering some
> info like terminology, how to help us, and so on...
>
> https://github.com/pharo-vcs/iceberg/wiki
>
> # And some videos ;)
>
> - Branching and merging https://www.youtube.com/watch?v=DBzkjwABPEI
> - Loading a Baseline https://youtu.be/brUHEOr-p_E
> - Contributing to Iceberg https://youtu.be/yGr5HvVWM0M
>
> # Changes Log
>
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.0.0
>
> Enjoy, Guille
>
> PS, detailed changes log below:
>
> # Cleanups
>
> #819 Fix tooltip typo in settings
> #800 Iceberg should be removed from the catalogue
> #801 Remove not referenced packages
> #803 Correct some lints in tests
> #806 Bad repair options when local repository is missing
> #725 Remove and clean old UI
> #794 Some classes should use category "utilities" instead of "utility"
> #791 Begin to remove old UI
> #734 Begin to remove old UI
> #576 Add link to github/gitlab ssh instructions
>
> # Enhancements
>
> #776 Upgrade to Commander 0.6.2  dependencies
> #765 Add command to copy SHA from history window
> #793 Add the commit message to history window
> #785 Metacello conflicts are not handled Metacello Integration
>
> # Bug fixes
>
> #771 IceTipRemoveFromRepositoryPackageCommand >> execute is not
> implemented
> #748 Code subdirectory in empty repository
> #767 Error while pulling with renamed packages
> #814 Moving extension from a package removes extended class
> #807 When we do not have the right to push on a report we get an Error
> instead of the pop up!
> #768 Inverse merge preview shows wrong diff
> #784 Pulling from a non existing remote branch fails#810 #removePackage:
> should recursively delete files
>
> # Documentation
>
> #702 Create screencast - How to contribute to iceberg
> #774 Copy Wiki contribution page to pharo-project/pharo wiki
>
> # Infrastructure
>
> #761 Make tests run in 64 bits Pharo 7
>
>

Re: [Pharo-users] [ANN] Iceberg v1.0.0

[Andrei Stebakov]

Is there support for HTTPS on Windows (or any plans to get it to work)?

On Tue, May 29, 2018 at 5:30 AM, Guillermo Polito  wrote:

> Hi all,
>
> Time for a new Iceberg update, that will be available in the next Pharo
> build. This time, there are lots of cleanups and enhancements. On the big
> highlights:
>
> - Tonel migration plugin is available in the "Other menu item"
> - Tests are green on 64 bits! (meaning iceberg can be safely used in 64
> bits).
>
> Thanks to everybody that participated in reviewing, opening/closing issues
> or even fixing a typo!
>
> # Documentation
>
> Just as a reminder, here you have a link to iceberg's wiki, convering some
> info like terminology, how to help us, and so on...
>
> https://github.com/pharo-vcs/iceberg/wiki
>
> # And some videos ;)
>
> - Branching and merging https://www.youtube.com/watch?v=DBzkjwABPEI
> - Loading a Baseline https://youtu.be/brUHEOr-p_E
> - Contributing to Iceberg https://youtu.be/yGr5HvVWM0M
>
> # Changes Log
>
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.0.0
>
> Enjoy, Guille
>
> PS, detailed changes log below:
>
> # Cleanups
>
> #819 Fix tooltip typo in settings
> #800 Iceberg should be removed from the catalogue
> #801 Remove not referenced packages
> #803 Correct some lints in tests
> #806 Bad repair options when local repository is missing
> #725 Remove and clean old UI
> #794 Some classes should use category "utilities" instead of "utility"
> #791 Begin to remove old UI
> #734 Begin to remove old UI
> #576 Add link to github/gitlab ssh instructions
>
> # Enhancements
>
> #776 Upgrade to Commander 0.6.2  dependencies
> #765 Add command to copy SHA from history window
> #793 Add the commit message to history window
> #785 Metacello conflicts are not handled Metacello Integration
>
> # Bug fixes
>
> #771 IceTipRemoveFromRepositoryPackageCommand >> execute is not
> implemented
> #748 Code subdirectory in empty repository
> #767 Error while pulling with renamed packages
> #814 Moving extension from a package removes extended class
> #807 When we do not have the right to push on a report we get an Error
> instead of the pop up!
> #768 Inverse merge preview shows wrong diff
> #784 Pulling from a non existing remote branch fails#810 #removePackage:
> should recursively delete files
>
> # Documentation
>
> #702 Create screencast - How to contribute to iceberg
> #774 Copy Wiki contribution page to pharo-project/pharo wiki
>
> # Infrastructure
>
> #761 Make tests run in 64 bits Pharo 7
>
>

[Pharo-users] Second Call for Papers: 11th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2018)

[Andrei Chis]

Call for Papers:
11th ACM SIGPLAN International Conference on Software Language Engineering
(SLE 2018)
co-located with SPLASH 2018
November 5-6, 2018
Boston, Massachusetts, United States
https://conf.researchr.org/track/sle-2018/papers


We are pleased to invite you to submit papers to the 11th ACM SIGPLAN
International Conference on Software Language Engineering (SLE 2018), held
in conjunction with SPLASH 2018 at Boston, Massachusetts on November 5-6,
2018.

---
Scope
---

With the ubiquity of computers, software has become the dominating
intellectual asset of our time. In turn, this software depends on software
languages, namely the languages it is written in, the languages used to
describe its environment, and the languages driving its development
process. Given that everything depends on software and that software
depends on software languages, it seems fair to say that for many years to
come, everything will depend on software languages.

Software language engineering (SLE) is the discipline of engineering
languages and their tools required for the creation of software. It
abstracts from the differences between programming languages, modelling
languages, and other software languages, and emphasizes the engineering
facet of the creation of such languages, that is, the establishment of the
scientific methods and practices that enable the best results. While SLE is
certainly driven by its metacircular character (software languages are
engineered using software languages), SLE is not self-satisfying: its scope
extends to the engineering of languages for all and everything.

Like its predecessors, the 11th edition of the SLE conference, SLE 2018,
will bring together researchers from different areas united by their common
interest in the creation, capture, and tooling of software languages. It
overlaps with traditional conferences on the design and implementation of
programming languages, model-driven engineering, and compiler construction,
and emphasizes the fusion of their communities. To foster the latter, SLE
traditionally fills a two-day program with a single track, with the only
temporal overlap occurring between co-located events.

---
Topics of Interest
---

SLE 2018 solicits high-quality contributions in areas ranging from
theoretical and conceptual contributions, to tools, techniques, and
frameworks in the domain of software language engineering. Topics relevant
to SLE cover generic aspects of software languages development rather than
aspects of engineering a specific language. In particular, SLE is
interested in contributions from the following areas:

* Software Language Design and Implementation
  - Approaches to and methods for language design
  - Static semantics (e.g., design rules, well-formedness constraints)
  - Techniques for specifying behavioral / executable semantics
  - Generative approaches (incl. code synthesis, compilation)
  - Meta-languages, meta-tools, language workbenches
* Software Language Validation
  - Verification and formal methods for languages
  - Testing techniques for languages
  - Simulation techniques for languages
* Software Language Integration and Composition
  - Coordination of heterogeneous languages and tools
  - Mappings between languages (incl. transformation languages)
  - Traceability between languages
  - Deployment of languages to different platforms
* Software Language Maintenance
  - Software language reuse
  - Language evolution
  - Language families and variability
* Domain-specific approaches for any aspects of SLE (design,
implementation, validation, maintenance)
* Empirical evaluation and experience reports of language engineering tools
  - User studies evaluating usability
  - Performance benchmarks
  - Industrial applications

---
Important Dates
---

All dates are Anywhere on Earth.

* Fri 29 June 2018 -  Abstract Submission
* Fri 6 July 2018 - Paper Submission
* Fri 24 August 2018 - Author Notification
* Fri 31 August 2018 - Artifact Submission
* Fri 14 September 2018 - Artifact Kick-the-Tires Evaluation Author Response
* Fri 5 October 2018 - Camera Ready Deadline
* Wed 10 October 2018 - Artifact Notification
* Fri 12 October 2018 - Deadline for Artifact-Related Paper Updates
* Sun 4 Nov 2018 - SLE Workshops
* Mon 5 Nov - Tue 6 Nov 2018 - SLE Conference

---
Types of Submissions
---

* Research papers
These should report a substantial research contribution to SLE or
successful application of SLE techniques or both. Full paper submissions
must not exceed 12 pages excluding bibliography.

* Tool papers
Because of SLE’s interest in tools, we 

Re: [Pharo-users] Lazy vs eager initialization

[Ramon Leon]

On 05/29/2018 08:49 AM, sergio ruiz wrote:
If a model has a list of things.. such as a user that can/may have lots 
of pets, are there any real benefits to initializing the list of pets 
lazily?


Yes, there's a huge benefit to lazy initialization; it's more resilient 
to class changes in the face of deserilization of old class shapes.  If 
you add new instance vars to a class, and then deserialize older version 
those instance variables will be nil.  With lazy init, this is not a 
problem.  Without lazy init, this is a null ref exception.


These old versions could be from a cache of data from the previous 
version of the code.  It's no fun to have to lose all cache data just 
because you push out a new version of the code.


In of the face of persistence, i.e. serialized versions of your objects, 
lazy init is the way to go.


--
Ramon Leon

Re: [Pharo-users] Lazy vs eager initialization

[sergio ruiz]

This makes sense.. in the the cases i am writing now, all objects will, by 
definition, have a bunch objects in the collection..

Thanks!



On May 29, 2018 at 12:02:53 PM, Norbert Hartl (norb...@hartl.name) wrote:

Lazy initialization is good if you only want to assign additional objects when 
needed. So if it would be a storage optimization you could make it in a way 
that only those who have pets get a collection assigned. 

peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: [Pharo-users] Lazy vs eager initialization

[Norbert Hartl]

> Am 29.05.2018 um 17:49 schrieb sergio ruiz :
> 
> If a model has a list of things.. such as a user that can/may have lots of 
> pets, are there any real benefits to initializing the list of pets lazily?
> 
> like:
> 
> self pets := OrderedCollection new.
> 
> vs.
> 
> pets
>  pets ifNil: [self pets: OrderedCollection new]
>  ^ pets
> 

Lazy initialization is good if you only want to assign additional objects when 
needed. So if it would be a storage optimization you could make it in a way 
that only those who have pets get a collection assigned. 
The downside is on the one hand that it raises concurrency problems because if 
two processes call #pets at the same time it could be that two collections are 
created and the two processes have each one of them and only one is stored in 
the pets holder. On the other hand lazy init makes you use the getter even 
inside the object (to assure the collection is created). I usually like to 
avoid having getters if not really needed but a lazy init style makes this a 
(bad) habit. 

So my advize would be that if you don’t have a reason to do so make the 
initialization of this collection in the #initialize method and use the instVar 
accessin the methods of the pets holder. Try not to have a getter for the pets 
collection

Norbert

[Pharo-users] Lazy vs eager initialization

[sergio ruiz]

If a model has a list of things.. such as a user that can/may have lots of 
pets, are there any real benefits to initializing the list of pets lazily?

like:

self pets := OrderedCollection new.

vs.

pets
 pets ifNil: [self pets: OrderedCollection new]
 ^ pets

thanks!


peace,
sergio
photographer, journalist, visionary

Public Key: http://bit.ly/29z9fG0
#BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV
http://www.codeandmusic.com
http://www.twitter.com/sergio_101
http://www.facebook.com/sergio101

signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Serge Stinckwich]

On Tue, May 29, 2018 at 4:15 PM Steffen Märcker  wrote:

> Dear Serge,
>
> on the VM mailing list, Levente pointed out, that this could also be
> related to some lib the VM uses (e.g., Freetype) that might change the
> rounding mode. I'll dig into it and give your idea a try and come back
> with the results.
>
>
I think it would be nice to have in Pharo 7. But before I want to make
> sure it a) works as expected and b) does not cause some nasty side effects.
>
>
​Yes in order to avoid any side effect, we can use what you propose before.
An API like :
Double roundToMinusInfWhile: [... code goes here ...]​

​so we don't expose the rest of the system to these modifications.

See you.​
-- 
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-users] Set Rounding mode for IEEE floating point operations

[Steffen Märcker]

Dear Serge,

on the VM mailing list, Levente pointed out, that this could also be  
related to some lib the VM uses (e.g., Freetype) that might change the  
rounding mode. I'll dig into it and give your idea a try and come back  
with the results.


I think it would be nice to have in Pharo 7. But before I want to make  
sure it a) works as expected and b) does not cause some nasty side effects.


Bye, Steffen


Am .05.2018, 12:26 Uhr, schrieb Serge Stinckwich  
:



On Thu, May 24, 2018 at 12:27 PM Steffen Märcker  wrote:


Hi,

now I've observed the same issue. It might be related to context
switching, since introducing a delay has a similar effect. Consider:

   | FE_TONEAREST FE_DOWNWARD FE_UPWARD FE_TOWARDZERO |
   FE_TONEAREST  := 16r.
   FE_DOWNWARD   := 16r0400.
   FE_UPWARD := 16r0800.
   FE_TOWARDZERO := 16r0C00.
   "For some reasons we have to call fegetround once."
   "c := LibC new fegetround."
   LibC new fesetround: FE_DOWNWARD.
   (Delay forSeconds: 1) wait.
   v1 := 1.0/10.0.
   LibC new fesetround: FE_UPWARD.
   v2 := 1.0/10.0.
   LibC new fesetround: FE_TONEAREST.
   v1 < v2.

If the delay is inserted, the script evaluates to false. Using the same
LibC-instance or creating a new one does not seem to change anything
here.
Interestingly, a similar approach in VisualWorks does not show this  
issue

yet.



​Ok, so maybe we need to use put evaluation in a block and use
valueNoContextSwitch ?
​Maybe use an API like the one you propose before :
Double roundToMinusInfWhile: [ ... ]




Actually, I expect the FE_* macros to be platform/implementation
dependent, as suggested here:

http://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/c/numeric/fenv/FE_round.html



​Ok.

Can we try to pack everything in a PR for Pharo 7.0 ?
​Thank you.

Re: [Pharo-users] Problem with PharoLauncher on Ubuntu 18.04 (64 bit)

[Francisco Lizarralde]

Hi Francisco,

> Le 29 mai 2018 à 00:30, Francisco Lizarralde francisco.lizarralde@
> a écrit :
> 
> Hi all,
> 
> I was using the PharoLauncher (32 bits) version on Ubuntu 14.04 (32 bits)
> without problem. But two days ago I installed Ubuntu 18.04 (64 bits) and
> tried to run PharoLauncher-linux-1.1-x64 and when I tried to run a 6.1
> image

It is not very surprising that you get problems when using 32-bits pharo
version on an new 64-bits system. With time, it is more and more difficult
to find compatible 32-bits libraries to install on these systems.
Did you follow instructions available at
https://pharo.org/gnu-linux-installation?

Hi Christophe,

Thank you for your prrompt reply.

Before I had a 32 bit PharoLauncher running on a 32 bit Ubuntu without
problem and now I do not have a 32 bit of PharoLauncher running on a Ubuntu
18.04. 

But now I have installed an all new  64 bit version of Ubuntu 18.04 and then
decompressed the PharoLauncher-linux-1.1-x64.zip and is with this version
that I have problems to run a 6.1 image.

I think the problem would be that PharoLauncher doesn't locate the path of
libc.so

"Error. Could not determine platform's libc path for VM. 
Try forcing $PLATFORMLIBDIR in /home/francisco/Pharo/vms/private/6521/pharo,
based on LIBC_SO."

But I don't know how to fix it. I will try to post the issue at
https://github.com/pharo-project/pharo-launcher/issues

Best regards.

Francisco




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

[Pharo-users] [ANN] Iceberg v1.0.0

[Guillermo Polito]

Hi all,

Time for a new Iceberg update, that will be available in the next Pharo
build. This time, there are lots of cleanups and enhancements. On the big
highlights:

- Tonel migration plugin is available in the "Other menu item"
- Tests are green on 64 bits! (meaning iceberg can be safely used in 64
bits).

Thanks to everybody that participated in reviewing, opening/closing issues
or even fixing a typo!

# Documentation

Just as a reminder, here you have a link to iceberg's wiki, convering some
info like terminology, how to help us, and so on...

https://github.com/pharo-vcs/iceberg/wiki

# And some videos ;)

- Branching and merging https://www.youtube.com/watch?v=DBzkjwABPEI
- Loading a Baseline https://youtu.be/brUHEOr-p_E
- Contributing to Iceberg https://youtu.be/yGr5HvVWM0M

# Changes Log

https://github.com/pharo-vcs/iceberg/releases/tag/v1.0.0

Enjoy, Guille

PS, detailed changes log below:

# Cleanups

#819 Fix tooltip typo in settings
#800 Iceberg should be removed from the catalogue
#801 Remove not referenced packages
#803 Correct some lints in tests
#806 Bad repair options when local repository is missing
#725 Remove and clean old UI
#794 Some classes should use category "utilities" instead of "utility"
#791 Begin to remove old UI
#734 Begin to remove old UI
#576 Add link to github/gitlab ssh instructions

# Enhancements

#776 Upgrade to Commander 0.6.2  dependencies
#765 Add command to copy SHA from history window
#793 Add the commit message to history window
#785 Metacello conflicts are not handled Metacello Integration

# Bug fixes

#771 IceTipRemoveFromRepositoryPackageCommand >> execute is not implemented
#748 Code subdirectory in empty repository
#767 Error while pulling with renamed packages
#814 Moving extension from a package removes extended class
#807 When we do not have the right to push on a report we get an Error
instead of the pop up!
#768 Inverse merge preview shows wrong diff
#784 Pulling from a non existing remote branch fails#810 #removePackage:
should recursively delete files

# Documentation

#702 Create screencast - How to contribute to iceberg
#774 Copy Wiki contribution page to pharo-project/pharo wiki

# Infrastructure

#761 Make tests run in 64 bits Pharo 7

Re: [Pharo-users] Problem with PharoLauncher on Ubuntu 18.04 (64 bit)

[Christophe Demarey]

Hi Francisco,

> Le 29 mai 2018 à 00:30, Francisco Lizarralde  
> a écrit :
> 
> Hi all,
> 
> I was using the PharoLauncher (32 bits) version on Ubuntu 14.04 (32 bits)
> without problem. But two days ago I installed Ubuntu 18.04 (64 bits) and
> tried to run PharoLauncher-linux-1.1-x64 and when I tried to run a 6.1 image

It is not very surprising that you get problems when using 32-bits pharo 
version on an new 64-bits system. With time, it is more and more difficult to 
find compatible 32-bits libraries to install on these systems.
Did you follow instructions available at 
https://pharo.org/gnu-linux-installation?
Prepare 64-bit-Linux for 32bit Pharo

The installation in Debian 8 Jessie 64bits and Ubuntu 14.04 and Later require 
some operations.

 sudo dpkg --add-architecture i386 
 sudo apt-get update 
 sudo apt-get install libx11-6:i386 
 sudo apt-get install libgl1-mesa-glx:i386 
 sudo apt-get install libfontconfig1:i386 
 sudo apt-get install libssl1.0.0:i386 

I would recommend you to use the 64-bits version of PharoLauncher: 
http://files.pharo.org/pharo-launcher/1.1/PharoLauncher-linux-1.1-x64.zip

Tell me if it is ok. If not, do not hesitate to post an issue: 
https://github.com/pharo-project/pharo-launcher/issues

Regards,
Christophe.


> I got this message.
> 
> Try this on a terminal:
> 
> cd "/home/francisco/Pharo/vms/private/6521" && export SQUEAK_PLUGINS="" &&
> "/home/francisco/Pharo/vms/private/6521/pharo" --nodisplay
> "/home/francisco/Pharo/images/Pharo 6.1 (stable)_1/Pharo 6.1
> (stable)_1.image" eval "(Smalltalk imagePath asFileReference parent) /
> 'pharo.version' writeStreamDo: [ :stream | |major minor|major :=
> SystemVersion current major.minor := SystemVersion current minor.(major = 6
> and: [ SystemVersion current highestUpdate >= 60509 ])ifTrue: [ minor := 1
> ].stream << major asString;<< minor asString ]"
> 
> And got this:
> 
> Error. Could not determine platform's libc path for VM. 
> Try forcing $PLATFORMLIBDIR in /home/francisco/Pharo/vms/private/6521/pharo,
> based on LIBC_SO.
> Please report what works to pharo [vm-dev] mail list.
>  LIBC_SO=
>  DISTRIB_ID=Ubuntu
>  DISTRIB_RELEASE=18.04
>  DISTRIB_CODENAME=bionic
>  DISTRIB_DESCRIPTION="Ubuntu 18.04 LTS"
>  NAME="Ubuntu"
>  VERSION="18.04 LTS (Bionic Beaver)"
>  ID=ubuntu
>  ID_LIKE=debian
>  PRETTY_NAME="Ubuntu 18.04 LTS"
>  VERSION_ID="18.04"
>  VERSION_CODENAME=bionic
>  UBUNTU_CODENAME=bionic
>  UNAME=Linux Dynabook 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17
> UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>  System seems to be 64 bit. You may need to (re)install the 32-bit
> libraries.
> 
> Do I really need to install 32-bit libraries ? 
> 
> Any advice will be apreciated !!!
> 
> Thanks in advance,
> 
> Francisco
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>