Re: [Pharo-dev] Some more effort to make Slang and VMMaker work on Pharo [for review]

[K K Subbu]

On 14/05/19 7:59 PM, Guillermo Polito wrote:


To do this work

- I had to review the AST-to-AST transformation, checking the output,
 comparing it to what squeak does and so on...


Guillermo,

This is a superb effort! Thanks. Are you planning to write a paper on 
this part of your work? A blog? It can open new vistas for research 
students in Pharo.


Regards .. Subbu

Re: [Pharo-dev] [ANN] Pharo 7.0 released!

[K K Subbu]

On 23/01/19 2:19 AM, Esteban Lorenzano wrote:

$ curl https://get.pharo.org  | bash
$ ./pharo Pharo.image eval "42 factorial”


This should be "curl -L" so that redirects are followed automatically.

Regards .. Subbu

Re: [Pharo-dev] ZeroConf trouble (curl/64bit)

[K K Subbu via Pharo-dev]

--- Begin Message ---

On 02/01/19 5:16 PM, Torsten Bergmann wrote:

Using ZeroConf on a fresh Ubuntu machine:

   wget -O- https://get.pharo.org/64 | bash

works but

curl https://get.pharo.org/64 | bash


Does curl -L help?

HTH .. Subbu

--- End Message ---

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[K K Subbu]

On Wednesday 11 April 2018 10:38 PM, Alistair Grant wrote:

StandardFileStream>>readInto:startingAt:count: assumes that
primitiveFileRead will always attempt to read count bytes, but it
actually only attempts to read 1.


StandardFileStream>>#basicNext uses

  position < readLimit ifFalse:

and does not check if the primRead returns < 0. Instead it should call 
whileFalse: and check if primRead returns <= 0 to check for EOF or error.


#primRead:... returns an error if the primitive fails and the file is 
closed. It should instead check for EOF or error and then return -1, 
otherwise it should return 0 (Data not ready?). Raise an error only if 
the underlying primitive fails for non-EOF cases.


Regards .. Subbu

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[K K Subbu]

On Wednesday 04 April 2018 09:07 PM, Sven Van Caekenberghe wrote:

Good summary, I agree.

Still, what are the semantics of #next - does the caller always have
to check for nil ? Do we think this is ugly (as the return value is
outside the domain) ? Do we then still need #atEnd ?


Senders of #next should be prepared to handle errors and EoS is just one 
of them.


On exhausting all elements in the collection, #next could block waiting 
for next object to become available or check for errors. Reading past 
End is just one of the error conditions. One way to recover from EoS 
error is to return an sentinel. The exact sentinel object could depend 
on the collection. Eliot suggested a good one earlier in this thread.


Regards .. Subbu

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

[K K Subbu]

On Wednesday 04 April 2018 04:06 PM, Nicolas Cellier wrote:

IIRC, someone said it is implemented as 'remaining size being zero'
and some virtual unix files like /dev/random are zero sized.


Currently, for files other than sdio (stdout, stderr, stdin) it is
effectively defined as:

atEnd := stream position >= stream size
I see a confusion between Stream and its underlying collection. Stream 
is an iterator and just does next, nextPut, peek, reset etc. But methods 
like size or atEnd depend on its collection and there is no guarantee 
that this collection has a known and finite size.


Essentially, a collection's size may be known and finite, unknown but 
finite size or infinite. This has nothing do with file descriptor being 
std{in,out,err}. If std* is a regular file or special file like 
/dev/mem, /dev/null, it's size is known at open time. With console 
streams or sysfs files, size is unknown until EOT (^D) or NUL is 
received. Lastly, special files like /dev/zero, /dev/random or 
/proc/cpuinfo don't have a finite size but report it as zero (!).


[ stream atEnd ] whileFalse: [ stream next. .. ]

will only terminate if its collection size is finite. It won't terminate 
for infinite collections.


Regards .. Subbu

Re: [Pharo-dev] [Testers Required] New FreeType implementation using FFI

[K K Subbu]

On Friday 30 March 2018 06:12 PM, teso...@gmail.com wrote:

32 bits: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-1142/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-32bit-b8d360a.zip


64 bits: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/job/PR-1142/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0-64bit-b8d360a.zip


Did a quick check by bringing up the image and running text related 
tests in Test runner. All tests ran with 0 failures.


Tested with get.pharo.org/vm70 (32-bit) and get.pharo.org/64/vm70 
(64-bit) on Ubuntu 16.04


HTH .. Subbu

Re: [Pharo-dev] "curl https://get.pharo.org/64 | bash" does not work (on Mac)

[K K Subbu]

On Sunday 25 February 2018 09:54 PM, Bernhard Pieber wrote:

Hi all,

Here is the output:
   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
  Dload  Upload   Total   SpentLeft  Speed
100   237  100   2370 0899  0 --:--:-- --:--:-- --:--:--   901
bash: line 1: syntax error near unexpected token `newline'
bash: line 1: `'

"curl https://get.pharo.org/64/ | bash" does work, though. It is just that in 
the documentation (https://get.pharo.org/64/) the link has no trailing slash.


The URL https://get.pharo.org/64 will return a 301 (Moved permanently) 
redirect reply. Unlike wget, curl will follow the redirect only if -L 
option is given, so


curl -L https://get.pharo.org/64 | bash

will also work fine. The document needs to be updated to use -L option 
for curl.


HTH .. Subbu

Re: [Pharo-dev] 64 bit VM build problems: gl.h not found, or glRenderer conflicts

[K K Subbu]

On Ubuntu 16.04, I had to use:

 sudo apt-get install uuid-dev libcairo2-dev libpango1.0-dev 
libgl1-mesa-dev libgl1-mesa-glx


to get all dependencies. This was sometime ago and the change should 
have made it to build.linux64x64/HowToBuild by now.


What exactly is your error message?

Regards .. Subbu

On Friday 26 January 2018 01:24 AM, Alistair Grant wrote:

Hi,

I'm attempting to build the 64bit VM in a docker container on Ubuntu
16.04 installing the required packages using
opensmalltalk-vm/.travis_install.sh, however B3DAcceleratorPlugin
fails to build because it can't find gl.h.

Installing mesa-common-dev (which is the most common answer when
searching for missing gl.h on google) changes the error to glRenderer
is redefined and has conflicting types.

Does anyone know what the correct combination of packages is?

Thanks!
Alistair

Re: [Pharo-dev] pharo --help returning non-zero exit status

[K K Subbu]

On Sunday 01 October 2017 11:27 AM, Peter Uhnák wrote:

Hi,

why does executing `pharo --help` return exit status 1? The operation 
succeeded, so I don't see a reason for a failure return state.


This is a bug. See the thread at


http://forum.world.st/Re-Pharo-dev-pharo-help-returns-exit-code-1-on-ubuntu-td4945756.html

The proposed fix is pending review at:

 https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/136

Regards .. Subbu

Re: [Pharo-dev] About cr and lf

[K K Subbu]

On Friday 04 August 2017 07:11 PM, Damien Pollet wrote:

Stream >> newLineFor: platform
 self nextPutAll: platform lineEnding



EOL encoding is a property of a text file and not a platform. While 
files created on a certain proprietary platforms ;-) may use an encoding 
that does not make it a platform property. Pharo should be liberal in 
accepting and preserving differently encoded files. E.g. Text editor vim 
has a setting (fileformats) for eol encoding to view or edit files with 
cr or crlf EOL encoding. If this is not set, vim falls back to nl.


I agree that existing messages like cr or nl should not be changed. 
Instead new methods (*eol) could be added to text files for decoding 
(read side) and encoding (write side). This should be liberal in 
accepting cr, nl, crnl decodes while reading a text file. While writing 
a new stream, eol should follow this order:

  1. if file eol property is set (cr/nl/crnl) it should use it
  2. else fallback to check platform eol property.
  3. Else, use cr (for backward compatibility with old files)
E.g.

 (aStream atEOL) ifFalse: [ c := aStream next ]
 aStream nextPutAll: 'hello world' ; writeEOL
 record := aStream readLine. "strip eol"
 aStream nextPutLine: 'hello world'

This is not going to be an easy change but it would make new code cleaner.

Regards .. Subbu

Re: [Pharo-dev] Discussing the roadmap

[K K Subbu]

On Friday 07 July 2017 03:26 AM, Eliot Miranda wrote:
Let's say that currently the mark-compact collector collects at about 
1Gb per second (that's about what I'm seeing on my MacMini for a 600Mb 
heap, collected and compacted in about 530ms on a 2.3GHz Core i7, = 
1.1Gb/s).  For the moment let's assume the GC scales linearly.  Then a 
10Gb server application will occasionally suffer 10 second pauses, which 
is unacceptable for any kind of high-availability server.  The total 
execution time overhead of GC may be in the 1%-10% range, but the pause 
times may be unacceptable (note that they're /not/ unacceptable for my 
employer's batch usage).


Good point! Object memory is a shared resource and like any shared 
resource will eventually become a bottleneck as it grows.


We could also tackle the problem of large apps with a different 
approach. The overheads of VM process may become negligible enough to 
make message passing across multiple co-operating processes more 
efficient than within a large monolithic process. E.g. if a computation 
of 1GB of data generates 10GB of garbage, then the extra 10GB need not 
be explicitly garbage collected if the task is done in a child (worker) 
process and terminated after the computed result is passed back to its 
parent.


Regards .. Subbu

Re: [Pharo-dev] FileReference>>/ and path canonicalisation

[K K Subbu]

On Tuesday 27 June 2017 05:01 PM, Sven Van Caekenberghe wrote:

A FileReference holds a FileSystem and a Path. A Path is just a
collection of elements that leads to a location, the leaf possibly
being interpreted as a file with an extension (although that last
point is just a convention). It seems great effort was put into
avoiding the use of separators.

Pharo is an object oriented system with appropriate abstractions,
FileSystem gives us one approach to this difficult problem.


+1. Pharo's elegant design captures the essentials of naming file objects.


In your reasoning, your truth, your reference is always the Unix file
system and the way paths are handled >FileLocator root / 'foo' /
'bar' / 'readme.txt'.

is more abstract (fitting to the original goal) then

'/foo' asFileReference / 'bar/readme.txt'.

because it totally avoids a reference to the platform dependent path
separator.


Agreed that the first form is quite elegant. But I see no harm in
graceful acceptance of the second. Such strings could be encountered in
scripts and variables. It is also a convenient shorthand.


Windows is an important target for Pharo, they use $\ not $/.


Windows cmd shell uses only $\ while its API accepts both. This is a
eternal meme thread in Win32 mailing lists ;-).


Another point is the distinction between internal/external and/or
concrete/abstract paths. Should something like '..' remain part of a
path. Never, always, only when it can be resolved ? What about
special characters ?


Path elements are platform-specific and their resolution to specific
inode is context-specific. Canonicalization is only needed in low level 
code.



Should we support ~ ? Sometimes I would like that too, but maybe

FileLocator home


Elements like ~ or $HOME are expanded by shell before calling host API.
GUI shells based on XDG also expand other variables (see
~/.config/user-dirs.dirs) It is upto Pharo to define its own variables
and expand them just before calling APIs (say from {$PHARO_HOME,
"pharo.conf"}

Regards .. Subbu

Re: [Pharo-dev] FileReference>>/ and path canonicalisation

[K K Subbu]

On Monday 26 June 2017 01:42 PM, Alistair Grant wrote:

1. Path's are canonicalised during initial creation, but are not when
extending the path, i.e. sending #/

E.g.

'/dev/shm/d1/d2/../t1.txt' asFileReference  " File @ /dev/shm/d1/t1.txt"

'/dev/shm/d1/' asFileReference / 'd2/../t1.txt'  " File @ 
/dev/shm/d1/d2/../t1.txt"

Automatic canonicalisation is problematic as the code doesn't handle
symbolic links in the path name:

('/dev/shm/d1/' asFileReference / 's3/../t2.txt') exists  " true (correct 
answer)"

'/dev/shm/d1/s3/../t2.txt' asFileReference exists  " false (wrong answer)"


The meaning of 's3/..' is ambiguous when s3 is a symlink. Should 's3' be 
resolved or not before #parent op is applied? Disambiguation depends on 
context, so early canonicalization is a bug.


My own preference is to not to canonicalize at all and 's3/..' should be 
left as {s3, ..}. See


  http://man7.org/linux/man-pages/man7/path_resolution.7.html


2. In an attempt to be completely general, the argument to #/ is assumed
to be a single directory / file.  This is incorrect as the path
delimiter is not allowed to be part of the file name.  The result is
that path comparisons and operations such as #parent give unexpected
results.


Path class>>from:delimiter has a bug. It attempts to canonicalize 
elements parsed from the String regardless of the context. If the code 
is changed to:


 pathClass withAll: (aDelimiterCharacter split: aString)

your test will pass.

I wonder why Path was subclassed from Object and not from 
SequenceableCollection?



My PR modified FileSystem so that:

1. Canonicalisation is separated out as an operation that has to be
manually requested:

'/dev/shm/d1/d2/../t1.txt' asFileReference  " File @ /dev/shm/d1/d2/../t1.txt"

'/dev/shm/d1/d2/../t1.txt' asFileReference canonicalize  " File @ 
/dev/shm/d1/t1.txt"


I am ok with this.


2. The argument to #/ can be either a single file / directory name or a
path.

('/dev/shm/d1/' asFileReference / 'd2/d3/t3.txt') parent  " File @ 
/dev/shm/d1/d2/d3"


ok with this too.


3. Adds unit tests to cover the changed behaviour.
...
Before I submit the patch, does anyone have any strong objections to the
changes as described above?


None from my side.

Regards .. Subbu

Re: [Pharo-dev] Doing a pull request

[K K Subbu]

On Friday 16 June 2017 10:57 PM, Esteban Lorenzano wrote:

Esteban,

Step 2 requires an issue to be created in Fogbugz. It would be nice
to do this within Pharo itself.

it would be, yes. I have even played with the idea of having a
“report bug” button on debugger for years now…

but then, someone has to program it:)


Juraj has already demonstrated FogBugz integration in his PharoSprint 
app. Extending to debugging or slicemaker could a nice project for 
students or in hackathons.


I have filed a case 20162 to track this:

 https://pharo.fogbugz.com/f/cases/20162

Regards .. Subbu

Re: [Pharo-dev] Doing a pull request

[K K Subbu]

On Thursday 15 June 2017 08:14 PM, Esteban Lorenzano wrote:

2. work on fix/change
3. commit/push to your repo
4. do a Pull Request once finished.


Esteban,

Step 2 requires an issue to be created in Fogbugz. It would be nice to 
do this within Pharo itself.


When creating an issue FB requires every detail to be filled in. Most 
issues arise while testing or debugging, so it would be easy to get most 
of the details from a debug session or test failure and then file an issue.


Regards .. Subbu

Re: [Pharo-dev] Doing a pull request

[K K Subbu]

On Wednesday 14 June 2017 08:25 PM, Rajula Vineet wrote:

Hi,

I am a GSoC student working on enhancing pharo command line interface. I was
wondering if there is a procedure to make a pull request to the Github repo.
It would be really helpful if someone can explain the right way of doing a
Pull Request. Thanks in advance.


Have you already forked the upstream project in github (aka base) and 
created a topic branch in your fork (aka head) to hold your changes? 
Please post them here or in Discord chat if you need detailed help. 
Follow the steps in :


 https://help.github.com/articles/creating-a-pull-request-from-a-fork/

Git jargon may be quite intimidating ;-) for first timers, but the 
procedure is really simple. Just remember to start with the "Pull 
Request" on the *base branch* and not your fork.


Regards .. Subbu

Re: [Pharo-dev] Pharo 7 and changes/sources files

[K K Subbu]

On Friday 09 June 2017 06:38 PM, Guillermo Polito wrote:

On Fri, Jun 9, 2017 at 2:51 PM, Yuriy Tymchuk 

Re: [Pharo-dev] remote development via VS Code

[K K Subbu]

On Thursday 08 June 2017 09:15 PM, Eliot Miranda wrote:

There are many things one could use this for, but one clear
direction, from the success of docker, is to make a Smalltalk image
observable and configurable by devops people without having to start
up an image and navigate an unfamiliar and foreign UI & IDE.  Such a
direction is probably not well served by a naïve mapping of classes
and methods to directories and files (what about global variables,
what about doits, what about Instantiation?) but the potential is
there.


FUSE is really useful for passive stores like zip, iso or tgz but not 
for suspended live object graph like an image. The toughest part here is 
not the mounting and name resolution but the semantic mapping between 
nodes and live objects.


I have a different suggestion that I feel is more 'Smalltalkish'.  It 
would be easier for us to build an object server thread into the VM to 
serve live objects in the image as a file hierarchy. It allows a finer 
control of object graph to filetree mapping. This encapsulates object 
implementation details in a single place (object manager) and respects 
platform-neutrality.


There is already a precedence in sysfs of Linux. It shows a live tree of 
device and drivers object graph - subsystems, buses, devices, their 
drivers and events. The code is under 1500 lines [1] because it 
leverages ramfs for name resolution and just has the semantic functions 
for just four concepts - directory, file, group and mount. It uses 
special filenames like 'uevents' to pass events between userspace and 
kernel (equivalent to user processes and vm plugins in our case).


The VM needs to have:
  a) a network responder (to listen and translate requests to paths 
(ordered collection of nodes),
  b) a name resolver to resolve paths to a name and name to a special 
object

  c) a semantic getter/setter to interpret these special objects.

So you could have:

  /globals//value
  /classes -> /globals/classes/
  /classes/Morph/instances/oop1/value, sizeInMemory etc.
  /objects -> /classes/Object/instances/
  /Undefined/doIt
  /Undefined/printIt

Instances don't comes with names one but they do have a unique id (oop) 
which can be mapped to a file (say oop%d). Indexed variables can be 
managed as 'group'.


[1] http://elixir.free-electrons.com/linux/latest/source/fs/sysfs

Regards .. Subbu

Re: [Pharo-dev] Problem opening UI saved images

[K K Subbu]

On Wednesday 07 June 2017 02:47 PM, Sven Van Caekenberghe wrote:

$ ./pharo-ui one.image

Does not open the UI, no window, hangs, no error, nothing. Since the
image itself still works, it must be a UI thing.


It works as expected on Linux (32-bit code running on
64-bit Ubuntu 16.04). We need to rule out any damage to the image header.

Is the savedWindowSize reasonable? e.g.

 $ od -An -j 24 -N 4 -t d2 1.image
665976

Does it work if the image is saved thru GUI?

What if the image is saved on Linux or Windows and then started on Mac OS?

Regards .. Subbu

Re: [Pharo-dev] please test download for Pharo 6.0

[K K Subbu]

On Wednesday 31 May 2017 07:48 PM, Esteban Lorenzano wrote:
Hello,

we are getting ready for release.
please take a minute to review:

http://pharo.org/STAGE.download


I uploaded some fixes for review after clearing them through testrunner. 
But Validation builds failed because of network timeouts, e.g:


[ ConnectionTimedOut signal: 'Cannot connect to ', (NetNameResolver 
stringFromAddress: hostAddress) , ':', port asString ] in Socket


as in 
https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator-simple/15867/artifact/report.html


Is this a temporary issue? When should I retry for review?

Thanks and Regards .. Subbu

Re: [Pharo-dev] please test download for Pharo 6.0

[K K Subbu]

On Wednesday 31 May 2017 07:48 PM, Esteban Lorenzano wrote:

Hello,

we are getting ready for release.
please take a minute to review:

http://pharo.org/STAGE.download


Quick feedback on Pharo linux/x86_64 on Ubuntu 16.04/64b.

I feel the Welcome page should point to HelpBrowser open instead of 
referring pharo.org because Pharo has a built-in help browser but not a 
WWW browser. The very first page should not lead to people to switch to 
a different app for help. Using help keeps people within the env and 
also leads them to learn how to create tutorials etc.


In Welcome/changelog/second item, Epicea is misspelled as Epica. Same 
doc, suggest renaming section heading for consistency - s/Tools/Tools 
related/ and s/Network/Network related/


"Learn Pharo Smalltalk" and "Explore Pharo Environment" dups references 
to books. The former could be merged into the latter to drive home the 
point that language and env are tightly coupled.


Also, merge "More Documentation" into "Getting help" and keep all web 
references together.


I can send in a pull request for these changes if it helps.

I tried to run:
  $ ./pharo-vm/pharo --nodisplay pharo-vm/shared/Pharo*.image eval 3+4

and got a usage error. The problem is that the pharo-vm/pharo script 
does not take into account option arguments and has other issues too. 
This works:


 $ ./pharo/bin/pharo --nodisplay pharo-vm/shared/Pharo*.image eval 3+4

HTH .. Subbu

Re: [Pharo-dev] basicNew usage pattern

[K K Subbu]

On Sunday 28 May 2017 02:09 PM, Ben Coman wrote:

Thanks Subbu.  That is a useful insight for me, but is about the
implementation.
My query was more about senders of basicNew, so is still open if you
have an opinion there, or anyone else.


It is just a private primitive for creating new instances. I don't think 
there is any restriction in the language that it should only be sent 
only from class-side methods. Only methods which are part of language 
implementation will send this selector and it so happens that most 
callers fall on the class side. You will also find instance side methods 
(operators) in non-trivial basic types like Colors or DateAndTime 
sending #basicNew.


Regards .. Subbu

Re: [Pharo-dev] basicNew usage pattern

[K K Subbu]

On Saturday 27 May 2017 01:41 PM, Ben Coman wrote:

A question arose in Discord regarding #basicNew, to which I felt like
the proper answer should be
that #basicNew is used only** from the class-side when making custom
initializers.
(**excepting special meta-handling like by Behaviour)


AFAIK, #basicNew is a low-level essential method which should *never* be 
overridden by application methods, while #new offers a stable facade 
over #basicNew for applications.


Essentially, #basic* methods are calls to primitives in VM which reify 
basic objects of the object model like float, symbols etc. They are 
coupled closely with interpreter and object memory structures and 
functions. Application classes do not concern themselves with size and 
layout of such objects and use the facade methods like #new.


It is like the difference between a system call and runtime C library 
function. A C function like malloc maintains a stable interface to the 
app while its makes different system calls on different OS implementations.


HTH .. Subbu

Re: [Pharo-dev] Booklet suggestion

[K K Subbu]

On Thursday 25 May 2017 05:33 PM, Ben Coman wrote:

Actually you stimulate my thoughts that the Help file might be a
better place for such snippets,
so they are always with the image, and don't need to be retyped.  Any
objections?


None. You could gather these under Help->Quick Guide or Help->Tips with 
a pointer to a larger collection.


Regards .. Subbu

Re: [Pharo-dev] Booklet suggestion

[K K Subbu]

Ben,

I think there is a deeper need here. Writing good document is hard and 
keeping it in sync with code is harder still.


A book/booklet separates content from the code and being frozen in time 
faces obsolescence. I would prefer to see a guidebook framework in Pharo 
that every package author can use to create a simple narrative on its 
features. Package authors and consumers have an incentive to keep the 
code and content in sync. If an Object is a recursion on the notion of a 
computer, why not provide, say a Note, as a recursive simplification of 
a book?


The framework could be on the lines of Plugins, Tests. E.g.

   Package-Core
   Package-Plugins
   Package-Tests
   *Package-Guide*

The guide framework should support active code (say to pop the source 
code for a method), active links to guides on which this package 
depends, automatic generation of table of contents, index of class 
references. Most of features already exists in Pharo but spread all 
over. They need a home.


A package could also extend this basic framework with features (e.g. PDF 
package could export articles to PDF, Zinc could generate HTML).


Regards .. Subbu

On Thursday 25 May 2017 07:03 AM, Ben Coman wrote:

I've seen a few requests for short bits of code to use in playground for
a demo presentation.  I wonder if it would be good to have a booklet to
gather these - seeded with Sven's excellent article...
https://medium.com/concerning-pharo/elegant-pharo-code-bb590f0856d0

It could include the recent meta-programming scripts like searching for
all class instance variables starting with a capital letter.

The book might be named "Snippets", in a format presentable to laser
print on-site - something physical for attendees to take away with them
to quick demo to others back in their office.

I can take the lead in setting it up.  Anyone remember any relevant
posts in our archives?

cheers -ben

Re: [Pharo-dev] Class syntax brainstorming

[K K Subbu]

On Monday 22 May 2017 05:32 PM, Denis Kudriashov wrote:

package: #MyPackage;
tags: #(Core);
layout: #MethodDictionaryLayout.


How about:
   properties: { #package->"My Package", ... }

A property dictionary would be a better option than named variables as 
it will not impose a burden on every class instance. It would also be 
easy to add new features to existing classes without breaking backward 
compatibility.


Regards .. Subbu

Re: [Pharo-dev] FileTree/Iceberg and SSDs, change the file format

[K K Subbu]

On Sunday 21 May 2017 11:34 PM, Dale Henrichs wrote:

As part of his work on Cypress 2.0 Martin McClure is planning on
supporting a file per class disk format in addition to the file per
method format and possibly a file per package format.

I'm not sure whether Martin is at the point where he is ready to share
his plans, but this is a problem that is being worked on and when Martin
is ready for feedback he'll publish his spec.


Is it possible to build a file responder right into Pharo and expose 
packages through WebDAV or FUSE or sshfs service? Then the contents can 
go directly from RAM (pharo) to RAM (repo server or git) without going 
through slow disk filesystem.


Regards .. Subbu

Re: [Pharo-dev] bug in command line handler

[K K Subbu]

On Friday 19 May 2017 05:40 PM, Damien Pollet wrote:

I wouldn't want to sound sarcastic, but I'm not sure there is such a
concept as "correct" in the context of ANSI escape sequences.
Still, according to the legends, 97 is supposed to be high intensity
white (for some subset of existing implementations).


;-). My context was command line usage in linux terminals.

Anyway, attached is a patch for the annoying bug which fixed the problem 
for me. I would appreciate if anyone else using the command line can 
confirm if the patch works for them. E.g.



$ ./pharo Pharo.image eval 'ProtoObject methodDict size\;^MProtoObject 
methodDict keys'

Syntax Error on line 1: 'Variable or expression expected'
=
1: ProtoObject methodDict size\;
  _^_
2: ProtoObject methodDict keys
$ ./pharo Pharo.image eval 'ProtoObject methodDict size.^MProtoObject 
methodDict keys;'

Syntax Error on line 2: 'Message expected'
==
1: ProtoObject methodDict size.
2: ProtoObject methodDict keys;
  _^_
$


Thanks .. Subbu


'From Pharo6.0 of 13 May 2016 [Latest update: #60473] on 19 May 2017 at 8:03:31.630191 pm'!
"Change Set:		resetcolor
Date:			19 May 2017
Author:			kks

reset colors after printing error messages while parsing"!


!STCommandLineHandler class methodsFor: 'printing' stamp: 'kks 5/19/2017 20:01'!
printCompilerWarning: aSyntaxErrorNotification
	| stderr position contents errorLine errorMessage maxLineNumberSize lineNumber |
	
	"format the error"
	position := aSyntaxErrorNotification location.
	contents := aSyntaxErrorNotification errorCode.
	errorLine := contents lineNumberCorrespondingToIndex: position.
	stderr := VTermOutputDriver stderr.
		
	"first gather the error title to be able to underline it properly"
	errorMessage := String streamContents: [ :s|
		s nextPutAll: 'Syntax Error on line '; 
			print: errorLine; nextPutAll: ': '; 
			print: aSyntaxErrorNotification errorMessage].
	
	 stderr red;
		nextPutAll: errorMessage; lf;
		nextPutAll: ('' padLeftTo: errorMessage size with: $=); lf;
		clear.
	
	"print each source line and mark the found syntax error"
	maxLineNumberSize := contents lines size asString size.
	lineNumber := 0.
	contents lineIndicesDo: [:start :endWithoutDelimiters :end |
		lineNumber := lineNumber + 1.
		lineNumber == errorLine ifTrue: [ stderr errorColor ].
		"0 pad the line numbers to the same size"
		stderr 
			nextPutAll: (lineNumber asString padLeftTo: maxLineNumberSize with: $0);
			nextPutAll: ': ';
			nextPutAll: (contents copyFrom: start to: endWithoutDelimiters);
			lf.
			"print the marker under the error line"
		(lineNumber == errorLine)
			ifTrue: [
	stderr nextPutAll:( '_^_' padLeftTo: position - start + maxLineNumberSize + 4);
			 lf;
			 clear]
	]! !


!VTermOutputDriver methodsFor: 'coloring' stamp: 'kks 5/19/2017 19:58'!
errorColor 
	self red! !

[Pharo-dev] bug in command line handler

[K K Subbu]

All,

I found an annoying bug with Pharo's eval command line handler. When it 
encounters a syntax error, the foreground color is set to red while 
printing error message, but not restored after (see attachment). I have 
to reset it every time using "echo -e \e[0m" :-(.


I found

STCommandLineHandler>>#printCompilerWarning: aSyntaxErrorNotification
...
"print the marker under the error line"
 (lineNumber == errorLine) ifTrue: [
stderr red
nextPutAll:( '_^_' padLeftTo: position - start 
+ maxLineNumberSize + 4);
lf ]]

The above code will leave the red color if the error happens on the last 
line (as in eval handler), then the color is never restored. Can someone 
confirm if this is indeed what is happening? I will file a case and post 
a fix, if so.


I also found VTermOutputDriver uses incorrect ANSI color codes (e.g. 
white is 37 instead of 97). If the current terminal bg color happens to 
be "stderr white", then the error text is unreadable.


Regards .. Subbu

Re: [Pharo-dev] Command line save and quit

[K K Subbu]

On Wednesday 17 May 2017 06:53 PM, Damien Pollet wrote:


| quit  |
quit := self commandLine hasOption: 'quit'.
(self commandLine hasOption: 'save')
ifTrue: [ Smalltalk snapshot: true andQuit: quit ].
quit
ifTrue: [ self exitSuccess ].

Here I'm guessing if you --save --quit then the image will get saved,
and next time it wakes up, enters the second conditional and
#exitSuccess… confusing :/


Thank you for making it clear. This is what intrigued me. I see many 
instances in pharo-project/pharo git where "--save --quit" is used. e.g.


scripts/export.sh:./pharo Pharo.image --save --quit ${PWD}/export.st

Regards .. Subbu

Re: [Pharo-dev] Current working directory

[K K Subbu]

On Wednesday 17 May 2017 05:08 PM, Rajula Vineet wrote:

Hi all,

I am working on improving pharo command line as a part of my GSoC project. I
have been looking at different current working directory implementations. I
have written a  blog post
   on it. It
would be of great help, if you can take a look and give your feedback.

Vineet,

Don't depend on getenv(). It is the parent (e.g. sh) which sets PWD to 
the current working directory before exec-ing your program. When a child 
process is spawned, the parent can decide not to pass this down to 
child. e.g.


$ env -u PWD ./try

Or, if the child process changes its working directory using chdir(), 
PWD will not change. e.g.


--- try.c ---
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
char cwd[PATH_MAX];

for(;;) {
if (getcwd(cwd, sizeof(cwd)) != NULL)
printf("getcwd: %s\n", cwd);
else
perror("getcwd() error");
printf("PWD: %s\n", getenv("PWD"));
if (argv[1]) {
printf("chdir %s\n", argv[1]);
chdir(argv[1]);
argc--; argv++;
}
else
break;
}
return 0;
}
---

Regards .. Subbu

Re: [Pharo-dev] Command line save and quit

[K K Subbu]

On Wednesday 17 May 2017 05:12 PM, Max Leske wrote:

Yes. #exitSuccess does a bit more:
1. return an exit code to the command line
2. print a message
3. check if the session has changed
4. allows for overriding and special handling of the Exit exception.

You should not assume that nobody needs that :)


Thanks for the quick clarification. I am trying to understand the 
difference between using quit and save/quit. exitSuccess never gets 
called when both options "--save --quit" are given. Shouldn't the code 
handle this case as well:


(self hasOption: 'save')
ifTrue: [ Smalltalk snapshot: true andQuit: false ].
(self hasOption: 'quit')
ifTrue: [ self exitSuccess ].

Regards .. Subbu

[Pharo-dev] Command line save and quit

[K K Subbu]

Hi,

STCommandLineHandler>>#end is defined as:
---
| quit  |
quit := self commandLine hasOption: 'quit'.
(self commandLine hasOption: 'save')
ifTrue: [ Smalltalk snapshot: true andQuit: quit ].
quit
ifTrue: [ self exitSuccess ].
---
Can this be simplified to:

^Smalltalk snapshot: (self hasOption: 'save')
  andQuit:  (self hasOption: 'quit')

Is it necessary to call exitSuccess when only '--quit' is given?

Regards .. Subbu

Re: [Pharo-dev] Does OSSubprocess works on ARM vm?

[K K Subbu]

On Tuesday 16 May 2017 04:26 PM, Denis Kudriashov wrote:


I checked again. It not works on Raspberry same way: empty string
returns. Not know how it would be on other Linux


If you run it from command line, does it list the files on the tty? Then 
it could be a bug in redirectStdout method.


HTH .. Subbu

Re: [Pharo-dev] Does OSSubprocess works on ARM vm?

[K K Subbu]

On Monday 15 May 2017 05:46 PM, Denis Kudriashov wrote:

OSSUnixSubprocess new
shellCommand: 'ls ~';
redirectStdout;
runAndWaitOnExitDo: [ :process :outString  |
^outString
].


What exactly are you trying to do? If you want the list of entries in ~ 
directory, you could use FileDirectory methods:


(FileDirectory on: (OSProcess thisOSProcess environmentAt: 'HOME')) 
entries collect: [ :f | f name ].


Regards .. Subbu

Re: [Pharo-dev] Does OSSubprocess works on ARM vm?

[K K Subbu]

On Monday 15 May 2017 03:31 PM, Denis Kudriashov wrote:


It returns empty string and console report:

ls: cannot access ~: No such file or directory

Any idea why it not works properly? (from command line "ls ~" returns
expected files).


~ is a shell language synonym for $HOME. Both are expanded by the shell 
before calling file syscall in the kernel. Kernel's filename resolver 
does not do ~ or $HOME expansions.


Regards .. Subbu

[Pharo-dev] Use of minimal image

[K K Subbu]

Hi,

I am tempted ;-) by the following message on Pharo's download page:
---
The minimal image is a reduced version of Pharo 7.0 (alpha): You have 
the most basic environment and you can interact with it via command 
line. WARNING: For hackers only!

---

What kind of hacking has been done with this image in the past ?

Can this image be used as a swiss-army knife for st (ala busybox in GNU)?

The image is small enough to ship as part of regular VM binary and 
plugins. If pharo (binary) is run without any image, this image can be 
used as a fallback to run st scripts. At launch time, we know underlying 
platform OS and architecture, so we could move a lot of 
platform-specific vm code into such st scripts.


Or, we could use it within Makefiles to build plugins outside of src tree.

Regards .. Subbu

Re: [Pharo-dev] ./pharo --help returns exit code 1 on ubuntu

[K K Subbu]

On Friday 05 May 2017 02:11 PM, Andrei Chis wrote:

...
./pharo -help
unknown option: -help
Common s:
  --help print this help message, then exit

Then `./pharo -help` returns an exit code of 1 on mac/linux while
`./pharo --help` returns a exit code of 0 on mac and 1 on linux.


It is --help on Pharo and -help on other compiles (see below). Can 
anyone shed light on the legacy compatibility comment in :


 platforms/unix/vm/sqUnixMain.c 
1421   /* legacy compatibility *//*** XXX to be removed at 
some time ***/

1422

1423 #ifdef PharoVM
1424 # define VMOPTION(arg) "--"arg
1425 #else
1426 # define VMOPTION(arg) "-"arg
1427 #endif


It's still not clear why running the vm to print the help of the version
should exit with an error code.


Agreed. I think --help and --version should return 0. I think the 1 was 
to catch incorrect/unknown arguments.


If I learn the rationale behind the change, I can propose a patch to fix 
this.


Regards .. Subbu

Re: [Pharo-dev] ./pharo --help returns exit code 1 on ubuntu

[K K Subbu]

On Friday 05 May 2017 03:01 AM, Andrei Chis wrote:

Any thoughts or places where I can look? This problem is still in the
latest vm.

Cheers,
Andrei

On Thu, Mar 30, 2017 at 9:37 AM, Andrei Chis > wrote:

Hi,

In an ubuntu installation with the latest vm and Pharo 6 image when
executing `./pharo --help` I get an error code of 1.
...
On mac the error code is 0. Also when executing './pharo' or
'./pharo Pharo.image --help' or './pharo --version' the error code
is 0 on both mac and linux.


That is strange. The source code returns 1 for both unix and Mac:

-platforms/Mac OS/vm/sqMacUnixCommandLineInterface.c 
  if  (!strcmp(argv[0], "-help"))   {
usage();
return 1; }
-platform/unix/vm/sqUnixMain.c
if  (!strcmp(argv[0], VMOPTION("help")))  { usage();  
return 1; }
---

BTW, the option is "-help" with a single dash. Two dashes will print the 
same because the option is not recognized. You may as well type 
"--hep" ;-).


Regards .. Subbu

Re: [Pharo-dev] Test and Patch for writeStream error

[K K Subbu]

On Tuesday 18 April 2017 10:51 PM, Alistair Grant wrote:

1. This is assuming that ensureEndsWith: is only used for strings, but
the implementation doesn't assume that (I tested it with an Array and it
was fine).
2. If you look at existing senders of ensureEndsWith: they check that
the string isn't empty.


In Pharo 5/6 WriteStream>>ensureCr does not. I guess this is one of 
those annoyances that most people just overlook. I happened to use 
generator.image from the command line in a small terminal window and got 
annoyed with all those blank lines. Chasing it down was more of a fun 
exercise in using Pharo.


I really appreciate you reviewing the code and your comments really made 
me study the fix more carefully. Thanks.


Regards .. Subbu

Re: [Pharo-dev] Test and Patch for writeStream error

[K K Subbu]

On Tuesday 18 April 2017 09:17 PM, Blondeau Vincent wrote:

Hi,

Thanks for reporting!

If you want to contribute and have your fix integrated, I advise you
to follow the procedure here: http://pharo.org/contribute-propose-fix


Thanks. I opened an issue and posted my fix for review at:

https://pharo.fogbugz.com/f/cases/19949

Change Sorter tool gave me some grief :-(. It didn't accept changes to 
preamble. I finally had to do


 (ChangeSet named: 'blahblah.cs') editPreamble

to prepare the changeset. The error exists in Pharo 6 also.

Regards .. Subbu

Re: [Pharo-dev] Test and Patch for writeStream error

[K K Subbu]

On Tuesday 18 April 2017 09:51 PM, Alistair Grant wrote:

This appears to be changing the meaning of #ensureEndsWith:.
The previous meaning was that it always ends with the supplied object.


The method name is ambiguous. If the collection is empty does it need an 
"ending"? All its senders use it for line/statement ending. If cursor is 
at the beginning of a collection, this becomes a null-op. This 
interpretation is also consistent with that of Squeak.



You've modified it to mean that an empty collection doesn't have the
object appended.


Yes, based on its usage. Otherwise, every new logger starts with a blank 
line :-(.



Is that really what the method is supposed to mean?  The comment matched
the previous implementation, with your change, it doesn't.

If the change does go ahead, the comment should be updated to reflect
the changed definition.


Good catch! I will update comments.


I'm also wondering why you've changed the test to hard-code a string
stream?


I just took a common usecase from CCodeGenerator.

Regards .. Subbu

[Pharo-dev] Test and Patch for writeStream error

[K K Subbu]

Hi,

I stumbled on an error in WriteStream>>ensureEndsWith: method. The error 
caused extra blank lines in logs.


Attached small changeset fixes it. It also adds a test to catch such 
errors in the future. With this fix,


./pharo generator.image PharoVMSpur32Builder buildUnix32

gives a compact output without extra blank lines.

To which box in which repo should I save this cs for mainlining it?

Regards .. Subbu
'From Pharo5.0 of 16 April 2015 [Latest update: #50770] on 18 April 2017 at 8:08:44.889256 pm'!
"Change Set:		fixcrs-kks
Date:			18 April 2017
Author:			kks

Fixed ensureEndsWith: for start of stream. The error was putting extra blank lines in log output"!


!WriteStream methodsFor: 'accessing' stamp: 'kks 4/18/2017 19:59'!
ensureEndsWith: anObject
	"Append anObject to the receiver IFF there is not one on the end."

	(position == 0 or: [(collection at: position) = anObject]) ifTrue: [^self].
	self nextPut: anObject! !


!WriteStreamTest methodsFor: 'testing' stamp: 'kks 4/18/2017 19:57'!
testEnsureEndsWith
	"self debug: #testEnsureEndsWith"
	| stream |
	stream := String new writeStream.
	stream nextPutAll: 'this is a test'.
	stream ensureEndsWith: Character cr.
	stream nextPutAll: 'for WriteStreamTest'.
	self assert: stream contents = (('this is a test' copyWith: Character cr), 'for WriteStreamTest').
	
	"Manually put a new line and verify there are no 2 new lines"
	stream := String new writeStream.
	stream nextPutAll: ('this is a test' copyWith: Character cr).
	stream ensureEndsWith: Character cr.
	stream nextPutAll: 'for WriteStreamTest'.
	self assert: stream contents = (('this is a test' copyWith: Character cr), 'for WriteStreamTest').
	
	"Test with a empty stream"
	stream := String new writeStream.
	stream ensureEndsWith: Character cr.
	self assert: stream contents = ''.! !

[Pharo-dev] Missing VMMaker repo in Pharo 6

[K K Subbu]

Hi,

I couldn't find the http://source.squeak.org/VMMaker repo in Monticello 
Browser list of repos. I have to add it to the downloaded image every 
time to work with VM :-(.


Is there any specific reason for not including it by default in Pharo 6 
(60465).


Regards .. Subbu

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[K K Subbu]

On Monday 17 April 2017 01:04 PM, Luke Gorrie wrote:


I wonder if some DWIM would make sense here. For example, my bash
wrapper that starts the VM could inspect the image file and decide which
VM is appropriate (spur, non-spur, 32-it, 64-bit, etc.) Otherwise the
user needs to guess and decipher cryptic error messages.


You can use the attached magic file with file(1) command:

 file -m magic  ...

to detect the image type. or register the patterns with binfmt_misc to 
match the vm to the image type automatically.


BTW, I goofed in my earlier email. I was using 64/vm60 and not 64/vmT60. 
Sorry for the confusion. With 64/vmT60, I use the following :


$ sudo prlimit --rtprio=2 --pid $$
$ ./pharo Pharo.image eval 3+4

Regards .. Subbu
# Smalltalk image file formats
0   lelong  6502Smalltalk image V3 32b  (%d)
!:mime application/squeak-image
0   belong  6502Smalltalk image V3 32b  (%d)
!:mime application/squeak-image
0   lelong  6504Smalltalk image V3 32b +C (%d)
!:mime application/cog-image
0   belong  6504Smalltalk image V3 32b +C (%d)
!:mime application/cog-image
0   lelong  68000   Smalltalk image V3 64b  (%d)
!:mime application/squeak64-image
4   belong  68000   Smalltalk image V3 64b  (%d)
!:mime application/squeak64-image
0   lelong  68002   Smalltalk image V3 64b +C (%d)
!:mime application/cog64-image
4   belong  68002   Smalltalk image V3 64b +C (%d)
!:mime application/cog64-image
0   lelong  6505Smalltalk image V3 32b +C+NF (%d)
!:mime application/cog-image
0   belong  6505Smalltalk image V3 32b +C+NF (%d)
!:mime application/cog-image
0   lelong  68003   Smalltalk image V3 64b +C+NF (%d)
!:mime application/cog64-image
4   belong  68003   Smalltalk image V3 64b +C+NF (%d)
!:mime application/cog64-image
0   lelong  6521Smalltalk image Spur 32b +C+NF (%d)
!:mime application/spur-image
0   belong  6521Smalltalk image Spur 32b +C+NF (%d)
!:mime application/spur-image
0   lelong  68019   Smalltalk image Spur 64b +C+NF (%d)
!:mime application/spur64-image
4   belong  68019   Smalltalk image Spur 64b +C+NF (%d)
!:mime application/spur64-image
0   lelong  68021   Smalltalk image Spur 64b +C+NF+Tag (%d)
!:mime application/spur64-image
4   belong  68021   Smalltalk image Spur 64b +C+NF+Tag (%d)
!:mime application/spur64-image

Re: [Pharo-dev] [Pharo-users] Pharo 6 snap install

[K K Subbu]

Luke,

I don't see this in the latest binary and I have not adjusted the rtprio 
figures at all. I can try running some simple tests if you send them to me.


$ curl get.pharo.org/64/60+vmLatest | bash


file Pharo.image
Pharo.image: Smalltalk image Spur 64b +C+NF+Tag (68021)

$ prlimit --rtprio
RESOURCE DESCRIPTIONSOFT HARD UNITS
RTPRIO   max real-time priority00

$ pharo-vm/lib/pharo/5.0-201704120850/pharo --version
5.0-201704120850  Wed Apr 12 09:13:59 UTC 2017 gcc 4.6.3 [Production 
Spur 64-bit ITHB VM]
CoInterpreter VMMaker.oscog-eem.2188 uuid: 
ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2188 uuid: 
ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 12 2017
VM: 201704120850 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ 
Date: Wed Apr 12 10:50:48 2017 +0200 $
Plugins: 201704120850 
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Linux testing-gce-504e47eb-4202-4e16-92e1-3d42dab82e2f 
3.13.0-103-generic #150~precise1-Ubuntu SMP Thu Nov 24 11:05:34 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
plugin path: 
/opt/share/downloads/pharo/64/pharo-vm/lib/pharo/5.0-201704120850/ 
[default: 
/opt/share/downloads/pharo/64/pharo-vm/lib/pharo/5.0-201704120850/]


$ ./pharo Pharo.image eval 0 tinyBenchmarks
'923354373 bytecodes/sec; 82191014 sends/sec'

Regards .. Subbu

On Monday 17 April 2017 03:25 AM, Luke Gorrie wrote:

I have the VM building under nix from the master branch now. The build
is based loosely on the linux.64x64 mvm script so it's building a 64-bit
x86-64 VM. The pharo-vm commit I am testing is 1c38b03f (from wednesday.)

I have tried opening both Pharo-60465.image and Pharo-50771.image and
both give this error:

This interpreter (vers. 68021) cannot read image file (vers. 6521).


How come? Is this because I built a 64-bit VM? If I want to use those
images then should I build a 32-bit image instead? (Or none of the above?)

Then I found Pharo64-60465.image and this does open and display a window
but it's frozen and prints these messages:

pthread_setschedparam failed: Operation not permitted
This VM uses a separate heartbeat thread to update its internal clock
and handle events.  For best operation, this thread should run at a
higher priority, however the VM was unable to change the priority.  The
effect is that heavily loaded systems may experience some latency
issues.  If this occurs, please create the appropriate configuration
file in /etc/security/limits.d/ as shown below:

cat >cantFindOriginError
[ self cantFindOriginError ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed: in
Block: [ self cantFindOriginError ]
[ ^ aBlock value ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in
Block: [ ^ aBlock value ]
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
Error(Exception)>>signal
Error(Exception)>>signal:
ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
UnixEnvironment(OSEnvironment)>>getEnv:
UnixEnvironment(OSEnvironment)>>at:ifAbsent:
[ Smalltalk os environment at: aString ifAbsent: [ nil ] ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in
Block: [ Smalltalk os environment at: aString ifAbse\
nt: [...etc...
BlockClosure>>on:do:
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or:
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:
UnixResolver>>home
[ self home / '.config' ] in UnixResolver>>preferences in Block: [
self home / '.config' ]
[ ^ aBlock value ] in
UnixResolver(PlatformResolver)>>directoryFromEnvVariableNamed:or: in
Block: [ ^ aBlock value ]
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
Error(Exception)>>signal
Error(Exception)>>signal:
ExternalLibraryFunction(Object)>>error:
ExternalLibraryFunction(Object)>>externalCallFailed
ExternalLibraryFunction(ExternalFunction)>>invokeWithArguments:
UnixEnvironment(OSEnvironment)>>getEnv:
FFICalloutAPI>>function:module:


Googling around it sounds like this "origin error" is caused by not
finding the Sources file but I have provided the PharoV50.sources and
strace suggests that it is opened okay:


open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources",
O_RDONLY) = 3

open("/nix/store/w85ynpp3zm33k8h1hvzh2g7hf7ggwx1k-pharo-share-1.0/lib/PharoV50.sources",
O_RDONLY) = 6

So maybe the problem is that I need a different source file? Or maybe
that I should switch to a 32-bit