[Pharo-users] Playing with Pharo 7

[Konrad Hinsen]

Hi everyone,

after finishing the Pharo MOOC, I have started to play with a simple
project of my own, initially using Pharo 6.1. Since Pharo 7 seems to be
coming soon, I wanted to try it out, and that lead to a few practical
questions.

1) How do you move your personal environment to a new image? If I have
   to re-do my settings and re-load one by one the packages I use, I
   won't be trying out new images more than strictly necessary.

2) My test project lives on GitHub, so I fired up Iceberg under Pharo 7
   to load it. Works fine... but I cannot commit and push under Pharo
   7. Iceberg pretends that there are no changes. With Pharo 6.1, this
   works very well. Has the operation of Iceberg changed significantly?
   If so, what would be the best place to learn about this?

Any pointers would be appreciated!

Cheers,
  Konrad.

Re: [Pharo-users] Playing with Pharo 7

[Konrad Hinsen]

Am 25.11.18 um 22:35 schrieb Paul DeBruicker:


For #1:

Set up a Metacello Baseline for your project and then you can automatically
load your packages and settings into as many images as you like.

https://github.com/Metacello/metacello


Thanks for the pointer! Unfortunately all the documentation there 
assumes way more familiarity with Smalltalk than I have. And even a lot 
of familiarity with Metacello itself, as the documentation only explains 
the latest functionality.


The good news is that it refers to "Deep into Pharo", so I will download 
that book and see if answers my questions.


Konrad.

Re: [Pharo-users] Playing with Pharo 7

[Konrad Hinsen]

"Cyril Ferlicot D."  writes:

> There is also a recent guide here:
> https://github.com/pharo-tips-and-tricks/pharo-tips-and-tricks/blob/master/General/Baselines.md
>
> I don't know if it is more beginner friendly. Feedback is welcome.

Yes, it's a lot better for beginners because it actually explains what
baselines are and which roles they play, in addition to giving examples.

Thanks,
  Konrad.

[Pharo-users] Pharo 7 under Linux

[Konrad Hinsen]

Hi everyone,

I haven't had much success running Pharo 7 under Linux as follows:

  1. Install pharo-launcher

  2. Start pharo-launcher

  3. Create an image for the Pharo 7 development release

  4. Start that image.

It crashes at startup, claiming that libgit2 is missing. There is, 
however, a libgit2 located at


   $HOME/Pharo/vms/70-x64/lib/pharo/5.0-201806281256/libgit2.so

Is this a known problem? Is there a workaround?


Thanks in advance,

  Konrad.

Re: [Pharo-users] Pharo 7 under Linux

[Konrad Hinsen]

Hi Esteban,

> While it should not crash (just disable iceberg), it will be useful to
> know which kind of linux are you using.

It's Ubuntu 18.10. And it doesn't crash in the sense of crashing the VM,
there's just an error message that pops up when I start the image.
I didn't try to use that image after that, so perhaps it's just Iceberg
that is affected (bad enough, how can you work without Iceberg?).

I noticed something weird when inspecting the VM directory more closely:

   $ cd Pharo/vms/70-x64/lib/pharo/5.0-201806281256/
   $ ls -l libgit2*
   -rw-r--r-- 1 hinsen hinsen  13 déc.   9 10:54 libgit2.so
   -rw-r--r-- 1 hinsen hinsen 3019447 déc.   9 10:54 libgit2.so.0.25.1
   -rw-r--r-- 1 hinsen hinsen  17 déc.   9 10:54 libgit2.so.25
   $ cat libgit2.so
   libgit2.so.25$ 
   $ cat libgit2.so.25
   libgit2.so.0.25.1$

What I'd expect to be symbolic links (libgit2.so and libgit2.so.25) are
in fact text files containing another filename. I tried replacing them
by proper symlinks, but that doesn't change anything in the error
message.

Konrad.

Re: [Pharo-users] Playing with Pharo 7

[Konrad Hinsen]

On 26/11/2018 21:47, Cyril Ferlicot D. wrote:

> There is also a recent guide here:
> https://github.com/pharo-tips-and-tricks/pharo-tips-and-tricks/blob/master/General/Baselines.md
>
> I don't know if it is more beginner friendly. Feedback is welcome.

I did the ultimate test: I wrote my own Baseline using nothing but the
information from that document. It worked the first time I loaded it
into a new image!

The main open question left by the guide is how to find the URLs to your
dependencies. For packages from GitHub that is not too difficult, as the
packages' installation instructions provide the URL. But it took me a
while to figure out the URL for XMLParser, which I had installed via the
Catalog Browser. In the end I searched for XMLParser on the Web site of
smalltalkhub, where I found the URL.

Konrad.

[Pharo-users] (no subject)

[Konrad Hinsen]

Hi everyone,

I am confronted with an implementation choice that I expect to be not so
rare, and I wonder what "the Pharo way" is for dealing with it. I will
use a toy example for illustration, my real case is more complex but not
fundamentally different.

Suppose I want to represent arithmetic expressions that support various
operations (evaluation, simplification, compilation to whatever
language, ...). In the textbook discussion, I'd have a class hierarchy
such as

Expression (abstract)
   IntegerExpression
   VariableNameExpression
   SumExpression
   ProductExpression
   ...

What I really want is not some IntegerExpression, but plain Pharo
integers, and for variable names I want to use plain Pharo symbols.

>From my current understanding of Pharo, my options are

 1. Use wrapper objects for integers and symbols, i.e. have a class
IntegerExpression that stores an integer in an instance variable.

 2. Add the methods of my abstract Expression class to all the classes
representing integers and symbols.

 3. Implement my own dispatch that does not rely on method lookup.

None of these really looks attractive. 1) adds a lot of overhead, both
in the code ("IntegerExpression withValue: 5" rather than just "5") and
at runtime. 3) also adds a lot of overhead because I have to implement
my own dispatch. 2) would probably be the least effort, but looks like a
kludge.

For comparison, in the Lisp world (CLOS, Racket, ...) that I know much
better, I would use generic functions and provide implementations for
integers and symbols as well as for my own Expression types.

So... how would you approach this problem?

Thanks in advance,
  Konrad.

Re: [Pharo-users] (no subject)

[Konrad Hinsen]

Richard Sargent  writes:

> I understand your desire to utilize the existing Smalltalk mechanisms. But,
> I think the most important thing is modelling consistency.
>
> What are the behaviours you expect from Expression, SumExpression, and
> ProductExpression? Do they know their parent expression? Their children?
> Other things?

I certainly agree that this should be the main consideration, but in my
case that's done. Each Expression subclass stored its own specific
information, which for leaf nodes such as integer expressions is really
just a value. All I need is integers with added behavior.

> I think that, in general, you will benefit from fully and consistently
> modelling the parse tree.

I should have mentioned that my Expressions are not parse trees. They
are used as values in symbolic computation. They are constructed and
deconstructed all the time, which is one reason I want to eliminate
overhead, the other reason being clarity of code.

Konrad.

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Konrad Hinsen]

Hi Offray and Doru,

allow me to chirp in on a topic that I have been thinking about for a
while:

>> Interesting observation. The linked tools as all other notebook
>> technologies I saw rely on two distinct modes for edit and view that
>> reside in two distinct widgets (editor and viewer). They do that
>> because they simply cannot have it in one. Because of the design of
>> Bloc we are not constrained to that. Instead, we build a seamless
>> interface that is both optimized for viewing, and for editing with
>> live preview that does not rely on an explicit render button. This
>> approach enables direct manipulation without friction, and we think
>> this is a significant advancement in this space.

> I don't think is only because other editors can't do it, but because
> some (most) times you don't want "to conflate two tasks that are
> /conceptually/ distinct and that, to ensure that people's time is used
> most effectively and that the final communication is most effective,
> ought also to be kept /practically/ distinct"[1] which are Composition
> and typesetting.

Two remarks.

First, this is a special case of the more general issue of having
multiple views and even multiple editors for a single object. No matter
what you believe to be the best approach to editing text with markup, in
many other situations it is clearly desirable to have multiple
views/editors side by side, and I have regretted more than once that
this doesn't seem to be possible in Pharo's inspector.

For multiple editors the need to have them side by side is probably more 
obvious than for mere views, so it may be useful to look at practical
examples and see how one would realize them in Pharo and/or in GT. One
of my favorite applications is graphics that are generated by program
code but can also be edited graphically, as implemented in
Sketch-n-Sketch (https://ravichugh.github.io/sketch-n-sketch/).
You definitely want the two panes, code and graphics, side by side.

Second, the example of editing text with markup also illustrates that it
matters if views are complete (i.e. show all the available data) or
partial, and if they are invertible, i.e. if a change in an editable
view can be translated unambiguously into a change in the underlying
data. Markup with comments, as mentioned by Offray, is a case in which
the rendered view is partial but nevertheless invertible, so it makes
sense to have two types of editors, one for the raw markup text and one
for the rendered version. Some people may want both side by side,
whereas others may prefer a single one with the possibility to switch,
depending on how important the non-rendered information is.

Scientific data visualization provides plenty of interesting examples by
the way, often with the additional challenge of significant
computational cost in rendering.

Konrad.

Re: [Pharo-users] Updating singletons

[Konrad Hinsen]

Hi Steffen,

Have you considered to yield (an) proxy object(s) instead of the actual  > Singleton in uniqueInstance? This way it suffices to update the proxy 

> with each update of the code.
I am not sure I understand what you are proposing. My problem is 
figuring out how to change in-memory objects when they become obsolete 
after a code change. So I'd say it doesn't matter much if the object I 
need to change is the singleton or a proxy to it, but maybe I am missing 
something!


Cheers,
  Konrad.

Re: [Pharo-users] Updating singletons

[Konrad Hinsen]

Dale,

> Did you try what I suggested and did it solve your problem?

I tried, but I see no difference. The postload method is still not
executed.

Konrad.

Re: [Pharo-users] Updating singletons

[Konrad Hinsen]

Hi Steffen,

> However, there is another fun possibility to figure out that a change  
> happened that does not involve configuration - though, a bit hacky. ;-)  
> You could write the accessor method such that it recompiles itself with  
> the first access after loading new code. For example:
>
>> Singleton>>uniqueInstance
>>  instance := self class new.
>>  self class compile: 'uniqueInstance ^instance'.
>>  ^instance

If I understand this correctly, it replaces the uniqueInstance method by
another one that returns the singleton instance. And when the code is
reloaded, it's the above method that is reinstated, to be used just
once. Neat!

Thanks,
  Konrad.

[Pharo-users] Documentation on Traits

[Konrad Hinsen]

Dear Pharo experts,

Is there any documentation on traits as implemented in Pharo 7? It's
easy to find discussions about the trait feature over the years, plus
slides and related stuff, but I am not sure what the current actually
implemented version is. I did manage to write and use a first trait
(https://github.com/khinsen/EqualityThroughVariablesTrait), but there
seem to be more advanced features such as slots that I don't know
anything about.

Cheers,
  Konrad.

Re: [Pharo-users] Documentation on Traits

[Konrad Hinsen]

Cyril Ferlicot  writes:

> There is documentation on Traits here:
> https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Traits.md

Great, thanks!

Konrad.

Re: [Pharo-users] [Iceberg] Loading my git project into a new image

[Konrad Hinsen]

Am 21.01.19 um 14:59 schrieb sergio ruiz:


I am not able to get the packages view to load on my project.

How would I go about creating a baseline?


Check out this explanation (with examples) :

https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md

Konrad.

[Pharo-users] PetitParser question

[Konrad Hinsen]

Dear parsing experts,

I have been working on a medium-size parser using the PetitParser
framework, which so far has been a very productive environment.  But now
I have a problem to which I could not find the solution in "Deep into
Pharo", nor by searching around in the code.

One of my production rules requires several parsed items to be equal.
It should accept expressions such as

1 + 3 + 2 + 6
2 * 9 * 3 * 6
0 - 8 - 5 - 3

but not expressions that mix different operators (because my grammar has
no precedence rules and thus requires parentheses for disambiguation).

In various other parsing frameworks, I do this by parsing up to the
first operator, retrieving it, and permitting only that same string in
the following. But I haven't found a way to do this in PetitParser, nor
any other obvious solution.

The only solution I see right now is to have one production rule per
operator, but that makes for a huge grammar. Is there another way?

Thanks in advance,
  Konrad

Re: [Pharo-users] PetitParser question

[Konrad Hinsen]

Dear Tomo,


This post might help you. In case of PetitParser2, it's PP2Failure instead
of PPFailure.
https://stackoverflow.com/questions/15371334/how-can-a-petitparser-parse-rule-signal-an-error


That's indeed a possible solution: parse for arbitrary operators, and 
then add a test for equality that can make everything fail in the end. I 
will try it out!


Thanks,
  Konrad.

Re: [Pharo-users] PetitParser question

[Konrad Hinsen]

Hi Doru,

Thanks for pointing out the use case in XML, which gave me an
opportunity to play around with this with almost no
effort. Unfortunately there seems to be a bug in how PPXmlParser
constructs the PPFailure message
(freshly reported:
https://github.com/moosetechnology/PetitParser/issues/38).

More generally, there seems to be a bug in how PetitParser handles
PPFailure return values. The actually reported error is always different
from what is passed to PPFailure. I love software ;-)

Konrad.

Re: [Pharo-users] PetitParser question

[Konrad Hinsen]

Tudor Girba  writes:

> But, does it solve your problem?

Not yet. Not sure it will.

>> More generally, there seems to be a bug in how PetitParser handles
>> PPFailure return values. The actually reported error is always different
>> from what is passed to PPFailure. I love software ;-)
>
> What do you mean?

If I return

PPFailure message: 'whatever' at: 0

from my parser, then it does fail but it reports a different error.

After some more experiments, it looks like this is perhaps not a bug,
but a feature that makes returning failures not so useful after all. I
suspect that PetitParser simply backtracks after my failure and tries a
different rule that then fails as well.

A simple example:

   | p |
   p := #digit asParser plus flatten
==> [ :value | value asSet size = 1 ifTrue: [ value ] ifFalse: 
[ PPFailure message: 'not equal' at: 0 ]].
   p parse: '22233'

The reported failure is "digit expected at 5".

On the other hand, if there is no path for backtracking, the reported
failure is the expected one:

   | p |
   p := (#digit asParser, #digit asParser) flatten
==> [ :value | value first = value second ifTrue: [ value ] 
ifFalse: [ PPFailure message: 'not equal' at: 0 ]].
   p parse: '23'

Konrad.

Re: [Pharo-users] PetitParser question

[Konrad Hinsen]

Tudor Girba  writes:

> Would this not work:

It works. And as much as I hate to admit it, my version of yesterday was
very similar except ... that it lacked a set of parentheses :-(

> Please note that I used PetitParser2 for this one because it also
> addresses the failure message issue you raised below. However, the
> logic would work in PP1 as well.

It does, but I ended up switching to PP2 as well to get the right error
messages.

Thanks a lot,
  Konrad.

[Pharo-users] Traits for class methods?

[Konrad Hinsen]

Hi everyone,

A quick question: is it possible to use traits to define class methods?

For example, could the popular singleton pattern consisting of the
three class methods #uniqueInstance, #new, and #reset plus the instance
variable uniqueInstance be packaged as a trait?

Konrad.

Re: [Pharo-users] Traits for class methods?

[Konrad Hinsen]

On 11/02/2019 17:18, Cyril Ferlicot wrote:


A quick question: is it possible to use traits to define class methods?

For example, could the popular singleton pattern consisting of the
three class methods #uniqueInstance, #new, and #reset plus the instance
variable uniqueInstance be packaged as a trait?

Hi,

Yes it is possible.


Thanks for your encouragement!

I ended up trying exactly that example, and it works just fine:

    https://github.com/khinsen/SingletonTrait

Konrad.

Re: [Pharo-users] Traits for class methods?

[Konrad Hinsen]

Marcus Denker  writes:

> It is amazing how much better this feels now that Traits can define state, 
> too… (compared to before where it was just methods).
>
>   
> https://github.com/khinsen/SingletonTrait/blob/master/SingletonTrait/SingletonTrait.trait.st
>
> I would even want to have (and use) a Trait like that in the system by 
> default.

That's what I thought as well when I saw the 43 implementors of
uniqueInstance in Pharo.

I'll package this as a pull request for Pharo!

Konrad.

Re: [Pharo-users] Iceberg working with forks - can it be easier?

[Konrad Hinsen]

Am 18.02.19 um 01:19 schrieb Tim Mackinnon:

Hey Ben - I’m not sure that this actually does the same thing. I just 
tried it now, and it resulted in an extra merge in my forked repo - as I 
think this effectively pulls down from upstream into pharo and then if 
you have any differences in your local image copy they might cause some 
changes which then you would push back into your fork origin.


If you just want a verbatim copy in your fork - you have to resort the 
command line?


That's at least what I do:

   git pull upstream master
   git push origin master

I am pretty sure these basic operations are somewhere accessible in the 
Iceberg code, but I have no idea how.


Iceberg would definitely gain from having a documented programmer's 
interface. Git is way too complicated for a point-and-click interface to 
be sufficient. I'd even say that "scriptable git" could become a Pharo 
killer feature if done well.


Konrad.

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

[Konrad Hinsen]

On 22/02/2019 15:57, Tim Mackinnon wrote:

I've just been caught out with Intervals - why can't you do:
5 to: 1 do: [ :i | Transcript show: i printString]  (eg a negative interval)?

if you want to iterate down a series of numbers do you really have to do:
5 to: 1 by: -1 do: […

I always assumed that if x > y the step was automatically -1 (but its not).


Expectations are obviously personal, but as far as I am concerned, I'd 
expect to see the behavior that Pharo implements. If you don't specify 
by:, you get a default value of 1. That's much simpler than a default 
value depending on the bounds of the interval.


Konrad.

[Pharo-users] Serializing classes with Fuel

[Konrad Hinsen]

Hi everyone,

does anyone here have some experience with Fuel?

Its Web site says "It can serialize/materialize not only plain objects
but also classes, traits, methods, closures, contexts, packages,
etc.". So I should be able to serialize a class somehow, right?

But classes are by default treated as global objects, even if they
aren't. The class I want to serialize is created by
newAnonymousSubclass. And yet, Fuel only stores its name in the output
file.

The documentation describes considerGlobal: which does the opposite of
what I want. So my question is: how can I tell Fuel *not* to consider a
class as global?

Konrad.

Re: [Pharo-users] Serializing classes with Fuel

[Konrad Hinsen]

Hi Mariano,

> Yes, that's the "default" behavior. To fully serialize classes you need
> FuelMetalevel packages. This brings a new visitors and mappers to allow you
> to fully serialize methods, classes, contexts, etc.

Thanks for the pointer - I will explore FuelMetalevel.

Konrad.

[Pharo-users] FUEL serialization to a file

[Konrad Hinsen]

Hi everyone,

after playing with FUEL in-memory (byte arrays) for a while, I am ready
to attack files. But... that's not so easy.

At
https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/Fuel/Fuel.html
I find the basic exxample

   'demo.fuel' asFileReference writeStreamDo: [ :aStream |
  FLSerializer newDefault
 serialize: 'stringToSerialize'
 on: aStream binary ].

It fails because ZnCharacterWriteStream does not understand #binary.

Browsing around a bit, I found another way:

   'demo.fuel' asFileReference writeStreamDo: [ :aStream |
  FLSerializer newDefault
 serialize: 'stringToSerialize'
 on: aStream binary ].

This works fine, the aStream being a ZnBufferedWriteStream. But on
larger objects, it ends up failing in

FLBufferedWriteStream >> #nextBytePutAll:

which sends the message

stream nextBytesPutAll: collection

But ZnBufferedWriteStream does not understand nextBytesPutAll: because
it is not a subclass of Stream for whatever reason.

Some further browing showed deprecated classes FileStream etc., and I
kind of suspect that file streams in Pharo were changed at some point
but FUEL still expects the old behavior.

Does anyone have an idea how to fix this, or work around it?

Thanks in advance,
  Konrad

Re: [Pharo-users] FUEL serialization to a file

[Konrad Hinsen]

Sven Van Caekenberghe  writes:

> FUEL is a binary serialiser, in the new Pharo 7 stream approach, a
> stream is either binary or textual, not both, nor can they be switched
> on the fly.

OK, thanks for confirming my suspicion that there was a change in Pharo.

> FileLocator temp / 'test.fuel' binaryWriteStreamDo: [ :out | FLSerializer 
> newDefault serialize: { 'Foo'. #bar. Float pi. 42 } on: out ].

So what I have been using is correct.


Tim Mackinnon  writes:

> Hmmm - yesterday I had someone serialise their debug stack (the top
> right menu bar action) to a file and send it to me and it worked treat
> - so I wonder what the difference is?

The problem I have occurs in buffering code. I suspect that it happens
as a function of the size distribution of the objects that are
serialized.


The problem is best analyzed by looking at the implementors of
#nextBytesPutAll:. That's an extension method that Fuel puts on the
Stream hierarchy, including its own class FLBufferedWriteStream where
the method contains the lines

 collection size > (self buffer size / 2)
ifTrue: [ stream nextBytesPutAll: collection ]
ifFalse: [ self nextBytesPutAll: collection ] 

In the second line, it sends nextBytesPutAll: to the unbuffered
stream. Which should be fine if it inherits from Stream. But
ZnBufferedWriteStream does not inherit from Stream.

I tried unraveling the construction of ZnBufferedWriteStream, to use
directly its underlying stream:

| ref stream |
ref := FileLocator temp / 'test.fuel'.
stream := ref fileSystem binaryWriteStreamOn: ref path.
[ FLSerializer newDefault serialize: { 'Foo'. #bar. Float pi. 42 }
 on: stream ]
ensure: [ stream close ]

On a standard file, that yields a BinaryFileStream, and everything works
fine. But for my test cases I use a MemoryFileSystem, and then I get
the same problem again - MemoryFileWriteStream does not inherit from
Stream either.

I wonder what's wrong with the Stream class - why are there stream-type
classes that don't inherit from it?

Konrad.

Re: [Pharo-users] FUEL serialization to a file

[Konrad Hinsen]

Am 09.03.19 um 08:16 schrieb Konrad Hinsen:


In the second line, it sends nextBytesPutAll: to the unbuffered
stream. Which should be fine if it inherits from Stream. But
ZnBufferedWriteStream does not inherit from Stream.


The fix I found is simple, but I don't understand the whole system well 
enough to be sure that it doesn't cause trouble elsewhere. I added the 
method ZnBufferedWriteStream >> nextBytesPutAll:


  nextBytesPutAll: aCollection
  self nextPutAll: aCollection

and all my problems are gone.

Konrad.

Re: [Pharo-users] FUEL serialization to a file

[Konrad Hinsen]

Hi Sven,

Thanks for all that background information on the history of streams. It
makes everything a lot clearer for me.

> But first, it would help a lot that you give a self-contained
> reproducible snippet that raises your problem, like mine. I tried
> reproducing your failure but could not.

My bug is difficult to reproduce because it is triggered only when the
"right" kind of buffer overflow happens. I didn't succeed yet to provoke
it while serializing simple objects such as strings or arrays.

I did manage to reduce my code quite a lot, so here is the shortest
example I have for the moment that provokes the bug:

   Metacello new
 baseline: 'ComputationalDocuments';
 repository: 
'github://khinsen/computational-documents-with-gtoolkit:minimal-code-for-serialization-bug';
 load.

And then

   APLibraryTest new setUp; testScanDirectory

Konrad.

Re: [Pharo-users] UI Frameworks

[Konrad Hinsen]

Bob Cowdery  writes:

> I also found Block and Brick which say they are next generation, Block 
> being for graphics and  Brick for widgets. These are not yet in Pharo 
> and again I couldn't find any info although there is a tutorial for 
> Block but not for Brick. Having forgotten most everything I knew I 
> didn't have much success trying to run the Brick examples.

The best existing illustration of what you can do with Bloc and Bric
is probably GToolkit: https://gtoolkit.com/. It also serves as a warning
that this is not ready for prime time yet. For example, the current
version crashes Pharo rather quickly if you use native windows. It isn't
a tutorial either, of course, but a huge reservoir of examples.

So an important consideration is your development time scale. If you
have a deadline for a usable product, better don't bet on Bloc and Bric
yet.

Konrad.

Re: [Pharo-users] [ANN] Pharo Days 2019 is online!

[Konrad Hinsen]

Esteban Lorenzano  writes:

> Currently we have 57 registrations.
> Let’s make it 60! Or 70! (Round numbers are better :P) 

I'd love to join but I have an agenda conflict with some classes I
teach. If you figure out a way to enable remote participation, I could
help increment that number ;-)

Konrad.

[Pharo-users] Iceberg for files other than code?

[Konrad Hinsen]

Hi everyone,

Is it possible to read and modify files not containing Pharo code in a
repository managed by Iceberg? I am thinking of reading the repository's
README file, for example, or storing data files read by my code
alongside the code itself.

Konrad.

Re: [Pharo-users] Iceberg for files other than code?

[Konrad Hinsen]

Hi Christopher and Tim,

Thanks for your comments!

I agree that managing the README from Pharo is not the most important
use case, I just mentioned it because everyone know what a README is.

A better example of what I want to do is Pharo's Help system. It stores
the individual pages as methods that return a literal string. That's one
way to store data in a package but it looks like a kludge. More
importantly, it is very difficult to use or edit the pages outside of
Pharo.

A better way to do something like that is to store pages as plain text
in the same repository as the classes that use them. But that requires
that the class can access the files as "file xx/yy/zz.txt in the same
repository from which my code was loaded". And if the class modifies the
text file, that change must be committed somehow.

I suspect that the read access part is doable somehow. The repository
checkout in pharo-local contains all the files, so it's just a matter of
figuring out the path. It's committing changes that requires some
support from Iceberg, which you says is not available if I understand
correctly.

Konrad

Re: [Pharo-users] Iceberg for files other than code?

[Konrad Hinsen]

Hi Tim,

> Hi Konrad - I think you can do what you describe - I think the
> ICeRepository entry for your project will have the path you want.

Indeed. Here's how to get the repository for class MyClass:

  repo := IceRepository registeredRepositoryIncludingPackage: MyClass
package.

And then the path ist just

  repo location.

> And yes, its the committing back non source files where iceberg
> doesn’t try to do anything (and so needs help from elsewhere).

>From what I saw so far it looks possible to change a file and do a
commit from Pharo code, bypassing the Iceberg UI. For some uses that
may be OK.

Konrad.

[Pharo-users] Creating a dictionary from a list of associations

[Konrad Hinsen]

Hi everyone,

About twice a week I start looking for a straightforward way to
turn a list of associations into a dictionary, spend a while searching,
and give up, ending up with a messy explicit loop.

Example:

   | words lengths |
   words := #('abc' 'defg').
   lengths := Dictionary new.
   words do:
  [ :each | lengths at: each put: each size ].
   lengths

Is there really no way to this with less code? I'd expect the following
to work:

   | words lengths |
   words := #('abc' 'defg').
   lengths := Dictionary withAll:
  (words collect: [ :each | each -> each size ]).

but it looks like Dictionary>>#withAll: was specifically designed to
make this impossible (because with the default implementation in
Collection it would work).

Konrad.

Re: [Pharo-users] Creating a dictionary from a list of associations

[Konrad Hinsen]

Hi everyone,

> About twice a week I start looking for a straightforward way to
> turn a list of associations into a dictionary, spend a while searching,
> and give up, ending up with a messy explicit loop.

Thanks for all the replies with interesting suggestions!

Gabriel Cotelli  writes:

> Dictionary newFromPairs: (words collect: [ :each | each -> each size
> ]).

Sven Van Caekenberghe  writes:

> { #foo->1. #bar->2 } #asDictionary
> 
> (#('abc' 'defg') collect: [ :each | each -> each size ]) asDictionary.

K K Subbu  writes (after correction):

> Dictionary newFromKeys: words andValues: (words collect: #size)


For my real-life use case, asDictionary is the most appopriate
choice. It does exactly what I need.

I had discovered newFromKeys:andValues:, which indeed is a good fit
for my small example, but not for my real applications, where the
list of associations comes from another method, so I can't change the
way it is constructed.

What I was most surprised about is newFromPairs:, which works as quoted
although its documentation says something else:

   "Answer an instance of me associating (anArray at: i) to (anArray at:
i+1) for each odd i.  anArray must have an even number of entries."

Konrad.

Re: [Pharo-users] Bloc of code in tiers programming language

[Konrad Hinsen]

Am 15.05.19 um 15:26 schrieb Atharva Khare:

I think in python, you use Lambda Expressions. Here is how I would do it 
in python3:

import math
f = lambda x: math.cos(x) + x
d_f = lambda x: (f(x + 1e-8) - f(x)) * 1e8


Lambda expressions are indeed Python's anonymous functions, but no 
Python programmer would create a lambda expression only to assign it to 
a variable. Doing this in an article to "sell" Smalltalk might well have 
the opposite effect.


Konrad.

[Pharo-users] An IPFS interface for Pharo

[Konrad Hinsen]

Hi everyone,

Over the last weeks I have started to explore IPFS more seriously.
IPFS, the Inter-Planetary File System, is supposed to be the
next-generation Web: a decentralized content-addressed database.

Since there is nothing better then Pharo for exploring databases,
I have started to write an IPFS interface to Pharo:

   https://github.com/khinsen/ipfs-pharo

It connects to a local IPFS server, so you have to have one
running. It's surprisingly straightforward to install and configure,
unless you have to fight with firewalls that block IPFS traffic.

Feedback of any kind is welcome!

Cheers,
  Konrad.

Re: [Pharo-users] An IPFS interface for Pharo

[Konrad Hinsen]

Am 06.06.19 um 19:37 schrieb Serge Stinckwich:


Great work ! I think Marcus was interested to have something like that.
It is a solution to distribute scientific datasets ?


That's what I am trying to explore. But IPFS is a nice basis for many 
more applications. I have seen an IPFS-based GitHub (Radicle), various 
social networks, personal information management (Textile), and a lot more.


Konrad.

Re: [Pharo-users] An IPFS interface for Pharo

[Konrad Hinsen]

serge.stinckw...@gmail.com writes:

> I would like something like that for Pharo images. Can you sync
> files.pharo.org on ipfs ?

That should be straightforward using nothing but the IPFS command-line
client. But it's worth thinking about the goals. What are you trying to
improve exactly? The main advantage that IPFS provides is the
possibility to create full or partial mirrors of the data (and thus
faster access), including on your personal machine. To make this
effective, you have to think a bit about good data management
strategies. Few people will want to mirror all the history of Pharo.
So you have to make interesting subcollections available under
permanent names (via IPNS).

Konrad.

Re: [Pharo-users] An IPFS interface for Pharo

[Konrad Hinsen]

On 11/06/2019 18:07, Stephan Eggermont wrote:

Konrad Hinsen 
wrote:
:

. To make this
effective, you have to think a bit about good data management
strategies. Few people will want to mirror all the history of Pharo.

Why? Fits on an SD card in a raspberry pi



All of http://files.pharo.org/ ? So how many GB is that?

Konrad.

Re: [Pharo-users] An IPFS interface for Pharo

[Konrad Hinsen]

Stephan Eggermont  writes:

>> All of http://files.pharo.org/ ? So how many GB is that?
>
> It is only a few thousand changes per release. There is no reason why that
> shouldn’t compress well

Did anybody try?

In IPFS, files are cut into blocks of roughly 256 KB. Blocks shared
between multiple files are stored only once. So if changes in Pharo
images from one version to the next happen mainly in one or two specific
places (such as beginning and end), they would be stored efficiently on
IPFS without any effort.

But again, the best way to know is to try it out.

Konrad.

Re: [Pharo-users] An IPFS interface for Pharo

[Konrad Hinsen]

Marcus Denker  writes:

> Indeed. Another thing to try: if someone has a local IPFS running, would it 
> cache
> only those images that either this machine or near machines requested?

Yes. But note that "nearby" is probably not what you expect, since IPFS
connects more or less randomly to other peers in the network. It's
neither geographically nearby nor nearby in the local network. All that
can be configured.

> This way we could have one “full” copy and caching (e.g. in the “African 
> class room” 
> example) would happen automatically.

That might work. A safer approach is to have one server machine in the
classroom on which the required files are pinned (IPFS jargon for "not
removed during garbage collection"). Then configure the other machines
nearby to "bootstrap" from that server.

> Of course the downside is that one needs to speak the IPFS protocol,
> thus either running a client (e.g the go client)… so real transparent
> use would only be possible if Pharo could implement the protocol…

The generally recommended way to use IPFS on a desktop machine is what I
do in my Pharo interface: connect via HTTP to go-ipfs running as a
daemon process. Even the IPFS command-line client does that. The
advantage is that you have only one data repository per machine, rather
than one per process.

For getting a Pharo image, you would then use the command-line
interface, or implement IPFS access in Pharo launcher via the daemon
(which should be straightforward, since it's really just an HTTP
request).

> There are many other ideas to explore (based on my partial knowledge)…
> more brainstorming than anything else:
>
> - Could we have an image formate that would be “block friendly”?

Probably. If some stable core is in one part of the image and the stuff
that changes with each release in another part, then many block could be
shared. Which IPFS does automatically.

> - How could one move resources out of the image into IPFS?

This is what I am currently experimenting with. My idea is to use IPFS
as something like an extended image, mainly for data that I would also
like to access from non-Pharo code.

> - Content addressing (like it is done in Git, too) and Objects, how can it 
> mix?
>   — Could one have “content pointers” instead of “memory pointers”?

It can certainly be done (just put all objects into a dictionary with
the hash as the key), but memory efficiency and access time could be
serious obstacles. This sounds more like a research project.

Konrad.

Re: [Pharo-users] [ANN] GitBridge

[Konrad Hinsen]

Am 16.07.19 um 22:07 schrieb Cyril Ferlicot D.:


Today I released the v1 of a project I wanted to do since a long time:
GitBridge.

The goal of the project is to easily access external resources stored in
the git repository of the project and other information.


Excellent - that's a functionality I have wanted for a while!

Thanks,
  Konrad.

Re: [Pharo-users] Ring, Athena, Rubric, Calypso, Morphic, Block,…

[Konrad Hinsen]

On 05/12/2019 14:27, Kasper Østerbye wrote:
I was wondering if there is somewhere all these subparts of Pharo are 
listed, and if it is also listed (and maintained) which ones are on 
their way out, and which are being updated and to what. I still find 
it truly  baffling.


Such a list would be great to have indeed!


Cheers,

  Konrad

Re: [Pharo-users] Floating point arithmetic

[Konrad Hinsen]

On 12/01/2020 21:13, Donald Howard wrote:

"Evaluate this in a playground and you'll see this is what
 floating point arithmetic produces --the first two are wrong, every 
one after is correct"

0.09560268 - 0.005 "=> 0.090602679".
0.0956026 - 0.005  "=> 0.090602599".
0.095602 - 0.005   "=> 0.090602".


Wrong in what sense? I am rather sure that the computation is done 
correctly, meaning that it follows the rules defined by IEEE standard 
754. I am also relatively sure (meaning a bit less) that the conversion 
of the binary result to a decimal output string is correct, in the sense 
that it applies today's preferred practice of ensuring round-trip 
equality. So you probably mean that the result is no what you expected.


The main point to be clear about is if you care about the binary value 
or about its decimal representation as a string. If you need the 
internal value to be exact, you have to switch to something other than 
binary floats - scaled decimals might work for you. If you only want 
nice-looking outputs, you can probably get what you want using roundTo: 
applied to the result.



Cheers,

Konrad.

[Pharo-users] Pharo 8.0 via get.pharo.org

[Konrad Hinsen]

Hi everyone,

it looks like get.pharo.org suffers from some confusion about its own
files. Here's what happens when I try to download the stable VM for
macOS:

   url https://get.pharo.org/64/vm80 | bash [8:01:43]
 % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
Dload  Upload   Total   SpentLeft  Speed
   100  5320  100  53200 0   110k  0 --:--:-- --:--:-- --:--:--  
112k
   Downloading the latest pharoVM:
http://files.pharo.org/get-files/80/pharo64-mac-stable.zip
   replace pharo-vm/Pharo.app/Contents/_CodeSignature/CodeResources? [y]es, 
[n]o, [A]ll, [N]one, [r]ename: new name: replace 
pharo-vm/Pharo.app/Contents/Info.plist? [y]es, [n]o, [A]ll, [N]one, [r]ename: 
error:  invalid response [{ENTER}]
   replace pharo-vm/Pharo.app/Contents/Info.plist? [y]es, [n]o, [A]ll, [N]one, 
[r]ename: error:  invalid response [if [ "$OS]
   replace pharo-vm/Pharo.app/Contents/Info.plist? [y]es, [n]o, [A]ll,
   [N]one, [r]ename: error:  invalid response [" == "win]
   ...

Closer inspection reveals that the script I get from

   https://get.pharo.org/64/vm80

downloads the zip file 

   http://files.pharo.org/get-files/80/pharo64-mac-stable.zip

which contains Pharo.app, not the VM to run from the command
line.

This looks like a bug, but not in Pharo. So... what's the right place to
report such a bug?

Cheers,
  Konrad.

Re: [Pharo-users] Pharo 8.0 via get.pharo.org

[Konrad Hinsen]

Norbert Hartl  writes:

>> which contains Pharo.app, not the VM to run from the command
>> line.
>> 
> This the same thing actually. For MacOS it is a bit cumbersome. You can start 
> the vm with 
>
> ./Pharo.app/Contents/MacOS/Pharo

OK, so the distribution format has changed from Pharo 7? What I got
before is a directory "pharo-vm" containing Pharo.app, plus two
scripts "pharo" and "pharo-ui" that facilitate execution from the
command line.

If the distribution format has indeed changed, then there's a bug in the
script that unpacks the zip file, and the documentation on
http://get.pharo.org/ is outdated as well. So my question remains the
same: what's the best way to report such bugs?

Cheers,
  Konrad.

Re: [Pharo-users] Pharo 8.0 via get.pharo.org

[Konrad Hinsen]

Hi Esteban,

> No it doesn’t :)
> What you are getting looks like an error that happen when you try to execute 
> zeroconf on top of an already existing zeroconf. 

Ahhh That explains everything. Here's what happened:
 - I tried downloading in a fresh directory
 - A second later, I had a power outage, and had to reboot my machine
 - Just to be sure I didn't have any corrupted files, I re-ran the VM
 download.

So yes, I already had some or perhaps all of the files in the directory.

> Can you try it on a clean directory?

Works fine!

Thanks,
  Konrad.

Re: [Pharo-users] Pharo #sum vs #sumNumbers and the consequence of #average

[Konrad Hinsen]

Am 23.03.20 um 14:45 schrieb James Foster:


On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe  wrote:

What you found out now is that the clever trick used to avoid picking an 
additive identity (picking an element, counting it twice and then subtracting 
it) leads to a loss of precision when floating point numbers are involved. This 
is an important issue.


If this approach is to be preserved, then each class should have an additive 
identity so instead of adding and subtracting an object, we let the object tell 
us its zero.


Or define a singleton class "Zero" with a + method that returns the 
other operand, and use that Zero object for the additive identity.


Konrad.

Re: [Pharo-users] New type of web application using HTML, CSS and Smalltalk

[Konrad Hinsen]

Hi Erik,



I have published my first demo of a new type of webapplication based on a
tiny Smalltalk image running in the browser, acting as the JS-engine. Create
a dynamic application using Smalltalk only, with the direct manipulation
you're familiar with from Smalltalk. And ...(in the near future)... with the
same debugging capabilities. Still work in progress, but hopefully providing
an idea of what's in store.



That demo looks very interesting! If I understand your architecture 
correctly, you have a minimal image run in the browser, presumably using 
a virtual machine written in JavaScript. The in-browser Smalltalk talks 
to a server written in Pharo, which is the development environment for 
Web applications. That all looks good.



What isn't clear to me is the autonomy of the in-browser system. Do you 
need the Pharo server only for development, or also for deployment of 
the final Web application?



Konrad.

Re: [Pharo-users] New type of web application using HTML, CSS and Smalltalk

[Konrad Hinsen]

Hi Erik,

> So it could be a way of creating standalone web applications. If that was
> the thought behind the question.

Exactly. Even better, a standalone application that could be hosted on
a plain static server, since all the code would run client-side.

> I did use this mechanism of creating snapshots in an attempt to strip down a
> regular Pharo image and create the small image to run inside the browser.
> Until I decided that route was longer than doing the bootstrap route of
> creating an image from scratch ;-).

That's also something I have been wanting to look at... why are days so
short?  ;-)

Konrad

Re: [Pharo-users] New type of web application using HTML, CSS and Smalltalk

[Konrad Hinsen]

Hi Craig,

>> ...Even better, a standalone application that could be hosted on
>> a plain static server, since all the code would run client-side.
>
>  E.g., https://caffeine.js.org/3d

Yes, caffeine is impressive, but also something very different from a
standard single-page Web app showing standard HTML elements and no IDE
in sight, in exchange for a small footprint.

Konrad.

Re: [Pharo-users] [ANN] Smalltalk's Successor

[Konrad Hinsen]

Am 12.08.20 um 06:28 schrieb Richard O'Keefe:

The contrast between "flexibility of choice" and "tyranny of one 
standard" is, um, a little over-drawn.  I have three different Common 
Lisp systems on this laptop: CMUCL, SBCL, and CCL.  I have the 
flexibility of choice between them *because* the adhere to a common 
standard.  Each of them has its own extra bits, but I am free to choose 
between them because everything *else* is not idiosyncratic.


Very true.

Software tends to form high stacks with many layers of dependencies. 
Productive work on any given layer requires stability in the layers 
below. But if anyone depends on *your* work, that's a constraint on your 
freedom to innovate.


Smalltalk today is in the same situation as Scheme (but unlike Common 
Lisp): there are more people interested in evolving Smalltalk than 
people building applications on top of Smalltalk. And that makes 
Smalltalk unattractive for those application builders for whom the 
progress in the quality of their tools is not worth the cost of the 
diversity and instability that require constant attention. It all 
depends on what you are working on, and in particular on the time scale 
of evolution of your work. If your application's requirement change 
rapidly, it's easier to deal with an unstable platform than if you are 
working on a complex design to be used over decades.


Konrad.

[Pharo-users] Pharo at JPL

[Konrad Hinsen]

Hi everyone,

I just saw the news (on Twitter) that JPL (NASA's Jet Propulsion 
Laboratory) has joined the Pharo Consortium. Does anyone here know what 
JPL is doing with Pharo? If it's related to scientific/engineering 
applications, that would be a nice marketing argument in the 
scientific/engineering community.


Konrad.

Re: [Pharo-users] Pharo at JPL

[Konrad Hinsen]

Hi Ted,

> I'm the person at JPL who (somehow) got "The Powers That Be" here to agree
> to join the Consortium.

Congratulations! That must have been a significant effort.

> I'm also the major champion of Pharo at JPL, and am leading an effort to get
> Pharo introduced & infused at JPL.

That's what I am most interested in. I am in biophysics research myself,
where Pharo is best described as invisible and unheard of. So I wonder
which techniques could work for introducing and infusing.

> I see the initial "market" for Pharo here to be:
>
> * Scientific & engineering data analysis & visualization,
> * Modeling and simulation, 
> * Internal web servers,
> * Custom ground support & test systems, 
> * Small-to-medium sized scripting to "support applications".

That looks like a lot of people to convince!

> I'm sure more application areas will open up as I get people to start using
> Pharo in their particular areas of expertise.

Indeed, the hard part is getting started.

> Wish me luck!

All you need!

Konrad.

Re: [Pharo-users] Rounding in Floats

[Konrad Hinsen]

Hi Esteban,

> It is not for printing but for testing. I want to assert that a
> certain calculation gives the expected result.
> And then it fails because of the difference above when it is
> "semantically" correct.

If you want reliable precision tests with IEEE floats, you should use
rounding to powers of 2, not 10. Round to 1/8 or 1/16, but not to 1/10.

The fundamental issue is that 1/10 does not have an exact finite
representation in base 2. No matter how I/O libraries handle the
conversion between base 2 (in the binary representation of IEEE floats)
and base 10 (in the text representation), there will always be bad
surprises because the expectations we have from working in base 10
cannot all be met with an internal representation in base 2. 

So if your goal is not fundamentally related to I/O, forget about I/O
and design your code to work the binary level, in particular for
testing.

However, if your problem specification explicitly requires precision
guarantees in base 10 (which seems to be your case, from a quick glance
at the Wikipedia page you cite), then it's best to avoid binary floats
completely. Rationals (fractions) are one option, scaled integers
another one.

Konrad.

[Pharo-users] Can a class be not equal to itself?

[Konrad Hinsen]

Hi everyone,


It's been a while since I have encountered mysterious behavior in Pharo, 
but today it happened. I set up a dictionary with classes as keys, and 
got "Key not found" errors for keys that were definitely in my 
dictionary. A quick debugging session showed the underlying issue: I had 
two references to a class which look the same when inspected, but turn 
out to be not identical (==) and thus not equal (=). How can this happen?



Konrad.

[Pharo-users] Re: Can a class be not equal to itself?

[Konrad Hinsen]

On 31/12/2020 12:19, Konrad Hinsen wrote:

It's been a while since I have encountered mysterious behavior in 
Pharo, but today it happened. I set up a dictionary with classes as 
keys, and got "Key not found" errors for keys that were definitely in 
my dictionary. A quick debugging session showed the underlying issue: 
I had two references to a class which look the same when inspected, 
but turn out to be not identical (==) and thus not equal (=). How can 
this happen?



Update, after a few more debugging sessions: my dictionary is the result 
of a deepCopy operation, meaning the class has been copied. And the copy 
of a class is indeed a distinct but otherwise indistinguishable class. 
'Object copy = Object' is 'false'.



Konrad.

[Pharo-users] Re: Can a class be not equal to itself?

[Konrad Hinsen]

"Richard O'Keefe"  writes:

> #deepCopy is one of those things that is best avoided,
> because it violates the key principle of OOP that an

In the abstract, I agree. In practice, I don't see what else I could do
for my use case. I have an object whose internal state is updated
by incoming messages. I need to take immutable snapshots of that
object's state at some points. And that I do by sending "deepCopy"
and then "beRecursivelyReadOnlyObject".

Benoit St-Jean via Pharo-users  writes:

> It never occurred to me that it would ever be the case!
> I've always thought classes were singleton and that SomeClass copy would 
> always return the sole instance of that class!

Me too. But after taking a closer look at how copy and deepCopy work, it
seems that maintaining singletons under copy operations is impossible.
There is no way to tell the copying machinery to return the original
object instead of making a new one. Unlike e.g. Python, where this is
possible and even quite common.

Konrad.

[Pharo-users] Re: Can a class be not equal to itself?

[Konrad Hinsen]

"Richard O'Keefe"  writes:

> Well, when you talk about "THE copying machinery" you have to be a bit more
> specific.  There is no such thing as #deepCopy or #shallowCopy in the ANSI
> Smalltalk standard.  Many Smalltalks have

I am referring only to Pharo, which is the only Smalltalk I have ever
used.

> You will note that in Pharo, AtomicCollection, Behavior, Boolean,
> Character, Float, SmallFloat64, Form, ColorForm, Morph, Paragraph,
> Point, SmallInteger, String, UndefinedObject, and perhaps others
> override #deepCopy.

Interesting. I didn't even consider this possibility because the comment
in Object>>#deepCopy says "should never be overridden".

> #deepCopy is *serious* "Hic sunt dracones" territory.
> It's marked on the Hunt-Lenox Globe, just beside the
> Vesuvian introitus ad infernum.

:-)  That's more or less what I discovered in my recent debugging
experiment.

> Seriously, the OOP way to do this is
> MyClass>>immutableSnapshot
>   "Answer an immutable copy of myself."
>   ...
> and then whatever it takes to make precisely that happen.

In other words, implement my own variant of deepCopy. That's probably
the safest way to go, but it also means there is no extensible
copying infrastructure that everybody can build on.

Konrad.

[Pharo-users] Re: Rounding in Floats

[Konrad Hinsen]

On 15/06/2021 01:03, Esteban Maringolo wrote:

Sure, but what initiated this thread was a reference to roundTo: 0.1
which produced a "wrong" output.

(9.1 + (-2.0)) roundTo: 0.1 "=> 7.1005"
7.1 roundTo: 0.1 "=> 7.1005"

However, at this point I know that Pharo "does the right, raw, thing"
(at least compared to other mainstream languages), but it still
produces a surprise effect.


That's the "floating point surprise" that everyone has at some point, no 
matter the language and runtime system. If that surprise is a problem 
for you, are you sure that floating-point arithmetic is what you really 
want? Maybe your needs are better served with integers and fractions.



Konrad.

[Pharo-users] Re: Rounding in Floats

[Konrad Hinsen]

On 15/06/2021 16:05, Esteban Maringolo wrote:

And in this particular case, it might cause issues, since the "full
precision" (whatever that means) must be retained when using such a
number to derive another one.


To me, "full precision" means "no precision is ever lost in arithmetic 
operations". If that's what you need, your choices are


1) Integers

2) Rational numbers (fractions)

3) Computable numbers (often called "exact reals", a term I find 
misleading).



Pharo has 1) and 2).


Konrad

[Pharo-users] Re: Rounding in Floats

[Konrad Hinsen]

On 16/06/2021 15:52, Sven Van Caekenberghe wrote:

I am also a bit intrigued by this. Like you said: several other programming 
languages (I tried a couple of Common Lisp and Scheme implementations) do the 
same as Pharo, but handheld calculators, normal and scientific, do not.


Handheld calculators use decimal floats, not binary floats. That doesn't 
remove rounding issues, but it makes conversion to and from print 
representations loss-free.



Konrad

[Pharo-users] Re: Rounding in Floats

[Konrad Hinsen]

Sven Van Caekenberghe  writes:

> It would be possible (and maybe it has already been done) to
> implement/add such a decimal floating point number to Pharo. It would
> require reimplementing all operations from scratch (esp. sin/cos/tan
> log/exp and so on), it would be slow, but interesting.

That would be an interesting experiment indeed. Either use one of the
IEEE754 decimal float formats
(https://en.wikipedia.org/wiki/Decimal_floating_point), or Douglas
Crockford's DEC64 proposal (https://www.crockford.com/dec64.html, which
strangely enough does not refer to the older IEEE standard). There are
implementations of both for various other languages that can serve as
inspiration.

Konrad.

[Pharo-users] Re: Introducing new feature dataTypes for the PolyMath/DataFrame project

[Konrad Hinsen]

Hi Balaji,

> Please go through the following blog post. Any kind of suggestion or
> feedback is welcome.

That's a nice description, easy to follow. But there is a missing piece:
how do you actually find the dataType for a series of values? My first
guess was that you are using the same method as Collection >>
commonSuperclass, but then a nil value should yield UndefinedObject, not
Object as in your example.

Cheers
  Konrad.

[Pharo-users] Re: Introducing new feature dataTypes for the PolyMath/DataFrame project

[Konrad Hinsen]

Hi Balaji,

> Thanks for pointing this out. You are right with how the data types are
> calculated, similar to collection >> commonSuperClass. But this time, it is
> calculated only during the creation of DataFrame once and for all.

That sounds good.

> A nil value, or a Series of nil values yields UndefinedObject as its super
> class. There was an error with the dataset used on that example blog post.
> I have corrected it now.

OK, that explains my confusion.

Cheers,
  Konrad.

[Pharo-users] Re: Introducing new feature dataTypes for the PolyMath/DataFrame project

[Konrad Hinsen]

"Richard O'Keefe"  writes:

> My difficulty is that  from a statistics/data science perspective,
> it doesn't seem terribly *useful*.

There are two common use cases in my experience:

1) Error checking, most frequently right after reading in a dataset.
   A quick look at the data types of all columns shows if it is coherent
   with your expectations. If you have a column called "data" of data
   type "Object", then most probably something went wrong with parsing
   some date format.

2) Type checking for specific operations. For example, you might want to
   compute an average over all rows for each numerical column in your
   dataset.  That's easiest to do by selecting columns of the right data
   type.

You are completely right that data type information is not sufficient
for checking for all possible problems, such as unit mismatch. But it
remains a useful tool.

Cheers,
  Konrad.

[Pharo-users] Re: Introducing new feature dataTypes for the PolyMath/DataFrame project

[Konrad Hinsen]

"Richard O'Keefe"  writes:

> Neither of those use cases actually works.

In practice, they do.

> Consider the following partial class hierarchy from my Smalltalk system:

That's not what I have to deal with in practice. My data comes in as a
CSV file or a JSON file, i.e. formats with very shallow data
classification. All I can expect to distinguish are strings vs. numbers,
plus a few well-defined subsets of each, such as integers, specific
constants (nil, true, false), or data recognizable by their format, such
as dates.

For internal processing, I might then want to redefine a column's data
type to be something more specific. In particular, I might want to
distinguish between "categorical" (a predefined finite set of string
values) vs. "generic string". But most of the classes in a Smalltalk
hierarchy just never occur in data frames. It's a simple data structure
for simply structured data.

> "You might want to compute an average..."  But dataType is no use for
> that either, as I was at pains to explain.  If you have a bunch of
> angles expressed as Numbers, you *can* compute an arithmetic mean of
> them, but you *shouldn't*, because that's not how you compute the
> average of circular measures.

I agree. There are many things you shouldn't do for any given dataset
but which no formal structure will prevent you from doing. Data science
is very much about shallow computations, with automation limited to
simple stuff that is then applied to large datasets. Tools like data
type analysis are no more than a help for the data scientist, who is the
ultimate arbiter of what is or is not OK to do.

Think of this as the data equivalent of a spell checker. A spell checker
won't recognize bad grammar, but it's still a useful tool to have.

Cheers,
  Konrad.

[Pharo-users] Intended behaviour of flatten and flatCollect:

[Konrad Hinsen]

Hi everyone,

I am getting surprising results trying to flatten nested arrays. So I
read the docstrings. And now I understand even less how flatten and
flatCollect are supposed to work.

flatten says:

"Recursively collect each non-collection element of the receiver and
 its descendant collections.  Please note, this implementation
 assumes that strings are to be treated as objects rather than as
 collection."

That suggests that

   #(1 2 3) flatten

should yield #(1 2 3). But it raises an exception, trying to send do: to
an integer.

A quick look at the code shows that flatten is just flatCollect: [
:each | each ]. flatCollect: says:

   "Evaluate aBlock for each of the receiver's elements and answer the
list of all resulting values flatten one level. Assumes that aBlock
returns some kind of collection for each element. Equivalent to the
lisp's mapcan"

"Flatten one level" is different from flatten's "recursively". The
assumption that aBlock returns a collection is also incompatible with
what flatten is supposed to do (and explains my exception).

I don't find the reference to a Lisp function very helpful. Assuming
"Lisp" means "Common Lisp", this confirms the docstring of flatCollect:,
this confirms the assumption of aBlock returning a collection, and that
only one level of nesting is flattened.

Since flatCollect does what it says, the problem seems to be in
flatten. Either its docstring or its implementation are wrong.

Or is it me misunderstanding something?

Cheers,
  Konrad

[Pharo-users] Re: Intended behaviour of flatten and flatCollect:

[Konrad Hinsen]

Hi Kasper,

Thanks for your reply!

> Sorry, but which version of Pharo are we talking about.


Sorry, I forgot to say that I am still using Pharo 9.

> I just tried with Pharo 10, which has no flatten method for arrays at

Interesting. So I double-checked - and found that the "flatten" in my
image actually comes from an add-on package called CollectionExtensions
(https://github.com/pharo-contributions/CollectionExtensions/blob/master/src/CollectionExtensions/Collection.extension.st).
 So
I will complain there :-)

> I am not going to comment on naming of such core api methods - they tend to 
> have 
> a 40 year history of forgotten arguments and random “clean ups”.

I agree, I didn't expect any level of homogeneous naming. Just an
agreement between code and documentation.

Cheers,
  Konrad

[Pharo-users] SmaCC: Adding conditions to production rules

[Konrad Hinsen]

Hi everyone,

I am stuck with a problem in SmaCC (of which I am a newbie user). Hoping
for suggestions from experts, any kind of pointer is welcome!

I have a production rule for infix operators:

  Term
: NonInfixTerm 'arg' ( 'opName' NonInfixTerm 'arg') * 
{{InfixOpTerm}}
| NonInfixTerm
;

According to the syntax rules of my language, infix terms are valid only
if all s are equal. Otherwise parentheses must be used to
disambiguate, as the language has no precedence rules.

How can I do this with SmaCC? I don't see how I could do it using the
basic features, but maybe with some tweaking on the Pharo side.

Thanks in advance,
  Konrad.

[Pharo-users] Re: Omnibase/Monibase repository removal

[Konrad Hinsen]

Hi Norbert,

> This means that I will remove the Omnibase repositories in few weeks from 
>
> https://github.com/ApptiveGrid/MoniBase 
> 
>
> and 
>
> https://github.com/pharo-nosql/OmniBase 
> 

I hope you are aware that all of GitHub is archived by Software
Heritage. MoniBase doesn't seem to be in there yet, but there are a few
repositories called OmniBase, some of which belong to accounts
associated with Pharo:

   
https://archive.softwareheritage.org/browse/search/?q=OmniBase&with_visit=true&with_content=true

Deleting a repository from GitHub doesn't delete its archival copy
on Software Heritage. Removal there has to be requested explicitly:

   https://www.softwareheritage.org/legal/content-policy/

Cheers,
  Konrad

[Pharo-users] Re: Sacrilegeous question : what are compelling use cases for Pharo

[Konrad Hinsen]

"Richard O'Keefe"  writes:

> Thus I hypothesise that there is room for Smalltalk as a tool for
> *generating* and configuring HPC code.

Yes. But it will be hard to convince people that Smalltalk is a better
choice than Python (well established in HPC as you say) for this use
case.

> My main worry is that when it comes to "bet your whole economy"
> software and worse still, "bet the entire global economy and human
> happiness for centuries" software like climate models, it's
> appropriate to use the very highest quality assurance tools practical,
> including *serious* verification.  That's not common practice.

Indeed, and that's one of my main worries in computational science as
well. There is a culture of scientific validation, but not of technical
verification of artifacts such as code.

My own project in this space (implemented in Pharo) aims at supporting
*human* verification for the aspects that no automatic tool can possibly
verify. In technical terms, that's verifying the formal specification
rather than the implementation of some method. The first step, which I
have made good progress on, is a specification language for scientific
models and methods that human readers would be happy to proofread.
Details:

   https://github.com/khinsen/leibniz-pharo/
   https://science-in-the-digital-era.khinsen.net/#Leibniz

Konrad

Re: [Pharo-users] (no subject)

[Konrad Hinsen via Pharo-users]

--- Begin Message ---
Thanks to everyone who replied - the sum of the answers is actually a
lot more useful than each one individually, as each one points to a part
of the puzzle that Pharo is (for me, at least, after roughly one month
of use).

Ben Coman  writes:

> This may not be what you are looking for, but maybe help flesh out ideas.
> Try debugging...
>  OpalCompiler new evaluate: '1 + 2'

An interesting experience indeed!

Tim Mackinnon  writes:

>  I was going to chip in that every class inherits what compiler it
>  uses and so you can easily override that to do something special
>  (like wrapping classes).

An interesting feature, though it seems a bit too low-level for my
project, and definitely too low-level for my current Pharo competence.

>  However, is this possibly an area where the meta-links kicks in so
>  you don’t have to do this and get a more generic solution? (I haven’t
>  played with this, but there are a few threads where people are using
>  it, and it’s progressed quite a lot in Pharo 7).

That sent me off research meta-links:

  https://pharoweekly.wordpress.com/2018/03/27/understanding-metalinks/

Interesting stuff as well, but the same comment applies: this looks too
low-level for what I consider boring code implementing routine
techniques.

Steffen Märcker via Pharo-users  writes:

> Did you already try to measure the impaired overhead of a wrapper
> solution? It might very well be negligible in an otherwise purely
> symbolic computation.

I did not look into performance questions at all for now. What scares me
most is the overhead in code size, in particular in my test suite.

> A hybrid solution might be - instead of wrapping each value - to add a  
> single method to the value classes that wraps a value on the fly if  
> needed, e.g.
>
> Integer>>asExpression
>^ExpressionWrapper wrap: self.

That looks like an interesting compromise, and one that I have seen used
elsewhere.

> Another option might be to build a trait that adds the behavior to the  
> value classes.

A nice suggestion as well - I haven't looked at traits yet in any
detail.

Serge Stinckwich  writes:

> in your case I would write a parser for your specific concrete syntax
> with PetitParser and then generate an instance of the abstract syntax
> you have defined.

My first reaction was that this looks like overkill for my problem. But
then, considering that I will eventually need a parser anyway, why not
start that way and use it in my own test cases? A path worth exploring.

Thanks again to everyone - your comments will keep me busy for a while!

Konrad.

--- End Message ---

Re: [Pharo-users] (no subject)

[Konrad Hinsen via Pharo-users]

--- Begin Message ---
Offray,

> It's really nice to have you hear. I remember some of our Twitter

Thanks for the welcome!

> I restarted with Pharo in 2014, after a short revealing experience with
> Squeak, EToys and Bots Inc in 2006-2007 and now I'm enjoying the Joyride[1]
>
> [1] https://twitter.com/offrayLC/status/493979407011561473

Nice :-)

I guess the tough part is figuring out where you are on that curve!

Konrad.

--- End Message ---

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

[Konrad Hinsen via Pharo-users]

--- Begin Message ---
Hi Doru and Offray,

Tudor Girba via Pharo-users  writes:

> A separate editor is needed when the markup has little resemblance
> with the output, which is the case for HTML. In this case,
> bidirectional editing, as shown in Sketch-n-Sketch, is indeed a very
> nice thing.

Or when the output reflects only a part of the input document. I suspect
Offray has the same kind of application in mind as myself, knowing a bit
of his work, and it is indeed a bit different from what you are
designing GT for. What we do (mainly) is documenting computations, not
software. A computation consists of code, input data, and selected
results.  This inevitably requires some metadata that needs to be
editable but should not necessarily appear in the output. The most basic
technology for documenting computations is the notebook (Mathematica,
Jupyter, ...) where the metadata is just the cell structure (which does
show in the output). More sophisticated systems (Emacs OrgMode for
example) allow more fine-tuning, making for much nicer output, but also
requiring quite a bit more metadata.

> However, in the case of Documenter and the Pillar markup the output is
> closely related to the sources part. In this case, having the two

>From what I know about Pillar, I agree. The way this is handled in
Documenter is indeed very appropriate for very simple markup like that.
And simple markup is highly desirable whenever sufficient.

> worlds be supported seamlessly in the same experience is a huge
> advantage, especially for non-technical people. The interface from
> Documenter is not trivially possible (I for now never saw one like
> that, and I looked specifically for it) because of the prerequisites

The closest I have seen is MarkText: https://marktext.github.io/website/
Its "focus mode" works much like Documenter in principle, but feels less
fluent somehow.


Offray Vladimir Luna Cárdenas via Pharo-users
 writes:

> but is not their only concern. ATM seems that new GT is pretty tied to
> Pillar and software documentation (which is fine, but not the path I'm
> primarily interested).

Me neither, but I still find a lot of interesting ideas in GT and I
suspect that a tool closer to my interests could be built with reasonable
effort from the bricks that GT provides.

My holy grail is a document that describes both software and
computations, combining the features of notebooks and literate
programming into a hypertext-like system in which I can start at the
surface (the computation) and "zoom in" to any part of the software,
getting documentation and not just source code.

Cheers,
  Konrad.

--- End Message ---

[Pharo-users] Updating singletons

[Konrad Hinsen via Pharo-users]

--- Begin Message ---
Dear Pharo experts,

I am wondering if there is a good way to deal with singleton objects
whose value needs to be updated following changes in the code that
initializes it.

Following the model of many examples in Pharo itself, I have defined a
singleton class with a uniqueInstance method for accessing (and creating
if necessary) the single instance, and a method "reset" marked as a
script to set the uniqueInstance back to nil when required, i.e. after
source code changes make the prior value inappropriate.

This works very well, as long as I don't forget to do the reset, which
has already caused me a few hours of debugging time. Worse, suppose
someone else is using my project in progress, pulling changes from my
GitHub repo once per week. That person cannot know if the latest changes
require a singleton reset. More importantly, users shouldn't have to
know about such internal details at all.

So is there a way to do the reset automatically whenever a new version
of my package is loaded into an image?

Thanks in advance,
  Konrad.

--- End Message ---

Re: [Pharo-users] Updating singletons

[Konrad Hinsen via Pharo-users]

--- Begin Message ---
Ben,

> You might use a Baseline #postLoadDoIt:
> https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md

Thanks, that looks like exactly what I need... except that it doesn't
seem to work. My postload method is not run when a new version of the
code is loaded into an image. Nor when I load my project into a fresh
image.

Which makes me wonder more generally how one can debug baselines. The
mechanism that uses them is very opaque: you write some code as a kind
of plugin to some framework, but it is not clear at all how this code is
used.

> Consider that a person pulling your changes cannot know if you have
> upgraded the library versions of any dependencies,
> so always updating via a Baseline might be a reasonable expectation.

Indeed, baselines make a lot of sense in principle.

Cheers,
  Konrad

--- End Message ---

Re: [Pharo-users] Updating singletons

[Konrad Hinsen via Pharo-users]

--- Begin Message ---
H Cyril,

> Fetching, loading and post loads should leave a trace during the
> execution in the Transcript.

Thanks, that helps to confirm that my postload is never executed when I
update a package + baseline in an image that already had an earlier
version loaded. Nothing at all is shown in the Transcript. Reloading the
package and/or the baseline package doesn't leave any trace either. And
if I add a dependency, then update the package again, the new dependency
is not loaded either.

Hypothesis: baseline changes have no effect for already installed packages.

When I load my modified package + baseline into a fresh image, lots of
actions are shown in the Transcript, including the execution of my
postload action. But in that situation, I don't actually need it.

Cheers,
  Konrad.

--- End Message ---

Re: [Pharo-users] Updating singletons

[Konrad Hinsen via Pharo-users]

--- Begin Message ---
Dale,

> This looks like a case where you are using a metadata-less repository 
> ... if so you, should add the following method to your baseline class:

Sorry, that's way above my understanding of baselines and repository
handling in general. I started from

  
https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Baselines.md

and adapted the examples there to my own situation, my project being
hosted on GitHub:

  https://github.com/khinsen/leibniz-pharo/

> This mod will cause packages to be unconditionally loaded ... Monticello 
> does a definition comparison on package load so only changed definitions 
> are loaded into the image ...

I'd say that a new dependency should be treated like a changed one, but
again I am still very much lost in the jungle of Monticello, Metacello,
Gofer, Iceberg, etc. It's the most opaque aspect of Pharo I have
encountered so far.

Cheers,
   Konrad.

--- End Message ---