Re: [Pharo-dev] [Esug-list] looking for input for a lecture on TDD and XtremeTDD

[Stephan Eggermont]

Hi Stef,

I’ve done some workshops and screencasts. In the workshops (oops, already a few 
years ago) I used a morph that was moving on the screen to emphasize the 
liveness. The BabyMock2 work by Attila Magyar is also great for that. It also 
is good to show the difference between Chicago and London style TDD, and 
connect to BDD. In Smalltalk, that is more represented by the exploratory 
modeling I was introduced to by Rob Vens. 

https://www.reflektis.nl/blog/exploratory-modelling-explained/

For a lecture TDD as if you meant is is a good starting point:

https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/

GToolkit of course provides some nice example-driven development, that combines 
well with literate programming 

In my latest screencasts I ran into the following issues:
- restarting a test does not make it green after going through it if it needed 
a fix
- can’t step into simple accessors (and other optimized code?)
- in addition to create, need to be able to create/change 
setUp/initialize/shutDown
- a refactoring ‘turn fake into class’ is missing where instVar := self and 
there are methods categorized as ‘faking instVar’

https://vimeo.com/329317634

https://vimeo.com/329368348

Stephan

Verstuurd vanaf mijn iPhone

> Op 14 apr. 2020 om 14:36 heeft Stéphane Ducasse  
> het volgende geschreven:
> 
> Hello 
> 
> I would like to build a lecture around TDD and XtremeTDD (coding in the 
> debugger). 
> I’m looking around to see if someone already did such a lecture. 
> 
> S. 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / http://www.pharo.org 
> 03 59 35 87 52
> Assistant: Julie Jonas 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 
> ___
> Esug-list mailing list
> esug-l...@lists.esug.org
> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Re: [Pharo-dev] Are people using the Pharo VM builds from BinTray?

[Stephan Eggermont]

David T. Lewis  wrote:
> Is anyone using the Pharo VMs from BinTray? Otherwise if it's not a problem
> for any Pharo users, I think the CI proprietors would like to turn off
> some of their unnecessary builds to save resources. My understanding is
> that the builds can easily be turned back on as needed in the future.

I use them once in a while. Useful when triangulating issues

Stephan

Re: [Pharo-dev] DrTest - strange UI effect and some feedback

[Stephan Eggermont]

Julien Delplanque  wrote:
> For the "Select none" I am not sure that we want to support that action 
> because it feels a bit odd. Why would one want to have nothing selected? 
> But if one can justify why this is needed, we can add it of course.
> 
> "Select inversion" could be added but again I think this is a bit odd 
> feature.

If you support select all you need at least one of invert selection and
select none. All actions are supposed to be reversible as far as possible. 

Stephan

Re: [Pharo-dev] Antlr4 + SmaCC

[Stephan Eggermont]

Nicolas Anquetil  wrote:
> On Thu, 2019-10-03 at 11:54 +0200, Santiago Bragagnolo wrote:
>> Hi there! 
>> I am trying to build a parser for visual basic. For doing so i found
>> the Antlr definition of VB on the microsoft site. 
> 
> I tried with fortran and the answer was: Not so easy.
> But then again, Fortran predates the theory of languages and it was not
> defined to be easily parseable with a formal grammar.

On the other hand, you know that you can parse these kinds of languages
with 16K of ram, one 80 character line at a time. 

Stephan

Re: [Pharo-dev] Difficulty to use Iceberg

[Stephan Eggermont]

Jan Vrany  wrote:
> Hi, 
> 
> I'm experiencing difficulties (code loss, even) when trying to 
> commit code using Iceberg. 
> 
> I have a project with consist of some Pharo code and some
> C++ code. Both parts kind of depend on each other. 
>...
> Any suggestions? 

https://github.com/jecisc/GitBridge might be of help here

Stephan

Re: [Pharo-dev] Pharo VM still crashing on Windows due to SSL

[Stephan Eggermont]

 wrote:
> Since my last post, Pharo is still crashing during installation of
> Seaside 3 in Windows 10 platforms. It happens because git uses SSL and
> there’s some bug that causes libssl to crash, killing VM.

With the latest vm?

Stephan

Re: [Pharo-dev] FW: Versioning with Iceberg

[Stephan Eggermont]

Cyril Ferlicot 
wrote:
>
> Configurations were managing project versionning and project
> dependencies while baselines are only managing the dependencies since
> the project versionning is done by git with it commit by project
> opposed to the commit by package of Monticello.

Ok, so that makes the handling of projects with lots of packages easier by
eliminating the simple problem of having to write down the exact version
number of these packages. That helps

Stephan

Re: [Pharo-dev] FW: Versioning with Iceberg

[Stephan Eggermont]

Sven Van Caekenberghe  wrote:
> 
> 
>> On 1 Jun 2019, at 10:41, Stephan Eggermont  wrote:
> 
>> Could you explain how configurations are simpler?
>> 
>> Stephan
> 
> Because BaselineOfs are simpler than ConfigurationOfs.
> 
> Of course, they don't do the same thing, since tags/branches in git manage 
> versions.

That is not what I see actually happening with baselines. They are
referring to branches and versions

Stephan

Re: [Pharo-dev] FW: Versioning with Iceberg

[Stephan Eggermont]

ducasse  wrote:
> Now migrating to iceberg is super easy and configurations are a lot
> simpler than with monticello. 

Could you explain how configurations are simpler?

Stephan

Re: [Pharo-dev] Handling of deprecation packages

[Stephan Eggermont]

Torsten Bergmann  wrote:
> The problem with the new vs. old streams seems to be that migration is
> unfinished even for the base image.
> Development already switched quickly to newer construction sites instead
> of finishing these old ones.

There are indeed several open issues with the new streams usage. I posted
one on the handling of filing in fileouts by drag and drop. 

The issue I see with existing code is mostly that an object is used as a
stream but is actually an information holder which understands much more
than the stream protocol. Rewriting that code to use a streamHolder can be
non-trivial. 

The fallback behavior of a readWriteStream opened on a read-only file is
also not easy to get right. 

Stephan

Re: [Pharo-dev] FreeType and the over amorous glyphs (overlapping)

[Stephan Eggermont]

teso...@gmail.com
 wrote:

> If somebody is willing to use it in Pharo 7, I can create a PR against
> Pharo7 to generate patched P7 images.

Yes, I want to

Stephan

Re: [Pharo-dev] PR2789, Rubric integration revert

[Stephan Eggermont]

ducasse  wrote:
> Hi stephan
> 
>> Unless someone is working on fixing it today, I want this PR reverted.
>> Issues 2865, 2963, 2964, 2980, 3013
>> 
>> Stephan
> 
> Nobody is working on Pharo this is well known.

I am feeling angry and ignored. I am trying to contribute and am frustrated
in doing so. I am asked to go through fogbugz and make sure that important
issues are reopened on github. I do so and get comments that bugs don’t
solve themselves, on the one where I notice that Rubric is not ready. I
find and fix important other bugs and try to integrate them and notice that
a lot of things don’t work as they should. CI has been systematically red.
The first thing I notice is that an in-image test is red, with a trivial to
fix issue. Then I run into all kinds of other problems with Rubric not
implementing something. And I’m not the only one, looking at the issue
tracker. So I look back trough github and see no signs of improvements in
the past 14 days. I collected the relevant issues and reached out on github
and discord first, without getting a useful reaction. This is not the
development process we are using, as I understand it. 

Please revert the PR. I have been working on FFI, Taskbar and CI bugs and I
want to be able to commit, integrate PRs and make Pharo better. Pharo is
mine.  

> 
> Sorry but I did not like the ton of your email, especially because there are 
> lot of information that you do not know. 

I’m up to date with the github commits, issues and PRs, Discord and the
mailing lists. If you feel contributors need more information, please make
sure we get it

> Now if you want to help, add the issue to the projects so that I can work
> on them with Alain
> and others. Else I will do it. 

Projects don’t work yet. 

If you want time to focus on Rubric only and don’t want other contributions
to Pharo 8 at the moment, then please announce so. Or use a branch. Don’t
integrate a PR that breaks CI and then don’t fix the issues for two weeks. 

Stephan

[Pharo-dev] PR2789, Rubric integration revert

[Stephan Eggermont]

Unless someone is working on fixing it today, I want this PR reverted.
Issues 2865, 2963, 2964, 2980, 3013

Stephan

Re: [Pharo-dev] Missing tests for FFI in CI

[Stephan Eggermont]

Guillermo Polito 
wrote:
>> 
>> BOOL GetExitCodeProcess(
>> HANDLE  hProcess,
>> LPDWORD lpExitCode
>> );
>> 
> 
> what are your mappings for BOOL, HANDLE and LPDWORD? Those are user defined
> types :)
> 

I downloaded the stable version of OSWindows from the catalog

Stephan

Re: [Pharo-dev] Missing tests for FFI in CI

[Stephan Eggermont]

ducasse  wrote:
> Hello Stefan 
> 
> Can you report the exact call you were doing? 
> I talked with G and Pablo and the bug they fixed is not the same. 
> Now they would like to experiment and write tests for all the platform. 

BOOL GetExitCodeProcess(
  HANDLE  hProcess,
  LPDWORD lpExitCode
);

I was trying to get the exit code of a running process on windows. That
didn’t work, so we started again with OSWindows on a clean Pharo 8. There
we noticed that the currentProcess was not [ 255 255 255 255 255 255 255
255] but [ 255 255 255 255 0 0 0 0]. That (and the test being green in 32
bit) triggered the idea. We did a quick and dirty change to verify, and
then found out that the Squeak code had cleaner fixes. 

Stephan

[Pharo-dev] Missing tests for FFI in CI

[Stephan Eggermont]

Yesterday, we tracked down a serious issue in 64 bit FFI. After giving up
with our own code, we made a fresh start with the latest base image and
OSWindows. We were finally able to figure out what went wrong with two
simple tests that were failing in 64 bit that worked correctly in 32 bit. 

FFIConstantHandleType externalType is the wrong size

After confirming that and making it work, we were told that a number of FFI
fixes were done by Nicolas and Eliot in Squeak that did not get integrated
in Pharo. Applying the changes from the latest Squeak FFI resolved the
problem, and a few that we were unaware of. 

Stephan

Re: [Pharo-dev] ZnBufferedReadStream and #upToAll:

[Stephan Eggermont]

ducasse  wrote:
> 
> I imagine that sven did not add it because on infinite stream it does not 
> make sense. 
> Now it would be good to see how we can have useful extensions. But I let this 
> to sven. 

That sounds like something that would be useful to make explicit:
isInfinite, with blocking, returning nil, returning null objects, or
returning errors as possible expected behaviors?

Stephan

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

[Stephan Eggermont]

Albrecht Baur via Pharo-dev
 wrote:

I started trying to do the same migration process for ...
http://www.smalltalkhub.com/#!/~Pier/Pier3
... but I failed on errors loading older mcz files:

"instance of ByteString did not understand #peek"
on: MCMczReader >> contentsForMember:
(ZnInvalidUTF8: Illegal leading byte for utf-8 encoding)

That needs a bugfix, old mczs might not be utf8. You can probably retry
with latin1 or macroman. Beware of issues like 
https://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008990.html

You might find WideString there, different encodings, or a dropped leading
character, and code where the method contents are changed but the timestamp
didn’t and the other way around

Stephan

Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write:

[Stephan Eggermont]

Sven Van Caekenberghe  wrote:
> 
> 
> "Check the selectors used in the latest packages on squeaksource, ss3,
> smalltalkhub and decide."
> 
> are pure technical, intellectual arguments and not passive-aggressive 
> criticism. Right. 

Yes, it is a very, very serious response. A few years ago I did some
prototypes with DeprecationFinder and MonticelloProjects, applying it to a
subsection of smalltalkhub. 
This is essential infrastructure. Both for deprecations and to recover
dependencies. Should be easy to get a paper out of it. 

Stephan

Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write:

[Stephan Eggermont]

Sven Van Caekenberghe  wrote:
.
> 
> So I propose to remove [Stream|Collection]>>#write:
> 
> What say thou ?

Check the selectors used in the latest packages on squeaksource, ss3,
smalltalkhub and decide. 

Stephan

Re: [Pharo-dev] Better management of encoding of environment variables

[Stephan Eggermont]

Guillermo Polito 
wrote:
> Hi Stephan,
> 
> I'm sorry for the noise.

No problem, just trying to understand where we want to go. 

Stephan

Re: [Pharo-dev] Better management of encoding of environment variables

[Stephan Eggermont]

Nicolas Cellier
 wrote:
> IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because
> the purpose of a VM is to provide an OS independant façade.
> I made progress recently in this area, but we should finish the
> job/test/consolidate.
> If someone bypass the VM and use direct windows API thru FFI, then he takes
> the responsibility, but uniformity doesn't hurt.

That sounds like a very good idea. Do you suggest to do that after the
Pharo 7 release? Or is it simple enough that it can be done in time? On the
unix side, do I need the explicit encoding or can I ask the OSEnvironment
for the one I need? 

Before the Pharo 7 release we need at least a #getEnv: back and a class
comment corresponding to what is expected. If we want to change to the new
API it needs to be deprecated. 

Stephan

Re: [Pharo-dev] Better management of encoding of environment variables

[Stephan Eggermont]

Guillermo Polito 
wrote:
> Hi all,
> 
> following the meeting we had here @Inria headquarters, I'll be backporting
> some of the improvements we did in the launcher this last month regarding
> the encoding of environment variables.
> 
> I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/
> 
> We have already studied possible alternatives with Pablo and Christophe and
> we have some conclusions and we propose some changes:
> 
> API Proposal for OSEnvironment
> =
> 
> 
>-
> *at: aVariableName *
> 
> Gets the String value of an environment variable called `aVariableName`
> It is the system reponsibility to manage the encoding.
> Rationale: A common denominator for all platforms providing an already
> decoded string, because windows does not (compared to *nix systems) provide
> a encoded byte representation of the value. Windows has instead its own
> wide string representation.
> 
>- *[optionally] rawAt: anEncodedVariableName*
> 
> Gets the Byte value of an environment variable called
> `anEncodedVariableName`.
> It is the user responsibility to encode and decode argument and return
> values in the encoding of this preference.
> Rationale: Some systems may want to have the liberty to use different
> encodings, or even to put binary data in the variables.
> 
>- *[optionally] at: aVariableName encoding: anEncoding*
> 
> Gets the value of an environment variable called `aVariableName` using
> `anEncoding` to encode/decode arguments and return values.
> Rationale: *xes could potentially use different encodings for their
> environment variables or even use different encodings in different parts of
> their file system.
> 
> Other Implementation details
> =
> 
>- VM primitives returning paths Strings should be carefuly managed to
>decode them, since they are actually C strings (so byte arrays) disguised
>as ByteStrings.
>- Windows requires calling the right *Wide version of the functions from
>C, plus the correct encoding routine. This could be implemented as an FFI
>call or by modifying the VM to do it properly instead of calling the Ascii
>version
> 
> 

What is the conclusion from this and issue 22658? See PR 2238. #getEnv: is
public API

Stephan

Re: [Pharo-dev] Bad baseline practices

[Stephan Eggermont]

Cyril Ferlicot 
wrote:
> On Tue, Jan 15, 2019 at 6:03 PM Stephan Eggermont via Pharo-dev
>  wrote:
>> 
>> 
>> 
>> I’m not sure why, but I’ve noticed baselines being changed to refer to
>> patch versions for releases. Why are the old configuration problems
>> repeated?
> 
> Which project are you talking about?

In a plain Pharo 7 image

BaselineOfCalypso
BaselineOfCommander
BaselineOfSystemCommands

Stephan

[Pharo-dev] Bad baseline practices

[Stephan Eggermont via Pharo-dev]

--- Begin Message ---


I’m not sure why, but I’ve noticed baselines being changed to refer to
patch versions for releases. Why are the old configuration problems
repeated? 

Stephan


--- End Message ---

Re: [Pharo-dev] Preparing the 7.0 release (and 8.0 open), we will need to rename "development" branch to "dev-7.0"

[Stephan Eggermont]

Christophe Demarey  wrote:
> Why not following git flow?

Because git flow has branches that don’t add value?

Stephan

Re: [Pharo-dev] halos

[Stephan Eggermont via Pharo-dev]

--- Begin Message ---
Esteban Lorenzano 
wrote:
> Then you need to be a bit more precise than just saying “it does
not works anymore” :)
> 
> Anyway, I can’t reproduce your problem.
> 
>  Pharo-7.0.0+rc1.build.1411.sha.56c2a7682674715623d89e8a16669397a1454e43 
> (64bit)
> 
> And latestVM, still works for me on windows.
> 

PharoLauncher Pharo 7 (development version) list isn’t updated anymore,
stuck at 1384. 1411 works for me too. 

Thanks,
  Stephan




--- End Message ---

Re: [Pharo-dev] halos

[Stephan Eggermont]

Esteban Lorenzano 
wrote:
> They work for me. 
> Same combination as always (alt+shift+click)

Not on 1384-64 in Windows with the latest vm

Stephan

[Pharo-dev] halos

[Stephan Eggermont]

What happened with halos in Pharo 7?  They don’t show up anymore

Stephan

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Stephan Eggermont]

Chris Muller  wrote:
>> Earlier, we’ve seen projects like Magma being overwhelmed by the number of
>> needed changes,
> 
> I'm curious what you meant by this.  I'm not aware of Magma ever
> having been overwhelmed.  Its design has made it easy to be one of the
> most-available and consumable pieces of software for every version of
> Squeak from 2007 to today.  Did you mean the Pharo port?  It doesn't
> really do any magic, I'd be surprised if it would be very difficult to
> port to Pharo, but I don't know.

Several people have been working on a Magma version for Pharo. At the time
(Pharo 1.0-1.2) the Pharo CI infrastructure was not giving enough feedback
to keep the port running. Once a year or so someone comes along who tries
fixing the port, and that appears to be too difficult or time consuming for
them. It needs pretty deep knowledge about internals. I agree that it would
probably not be very difficult for a long time pharo/squeak developer.
Finding out what exactly changed and why in the past 8 years is not so easy
for someone new. 

Without someone using it in production on Pharo, there is not enough
incentive to keep up with what changes in Pharo. There’s a chicken and egg
problem there

Stephan

Re: [Pharo-dev] [ANN] 22477 DelayScheduler cleanup and refactoring [was: Where do we go now ?]

[Stephan Eggermont]

Ben Coman  wrote:
> On Fri, 13 Apr 2018 at 13:56, Benoit St-Jean via Pharo-users <
> pharo-us...@lists.pharo.org> wrote:
> 

What is the current status of this? DelaySpinScheduler is default in my
recent Pharo 7 images and makes my images unusable on Ubuntu 18.04LTS. 

Stephan

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Stephan Eggermont]

Tim Mackinnon  wrote:
> 

> In retrospect,  I’m wondering if successful projects that have proved
> integration usefulness should be moved into the core repo?
> (Iceberg/Calypso?) or are we missing something to help easily track the
> journey of a multi faceted change (although this sounds overkill?). Or
> are there sprint days to try and knock these things through easily with
> everyone on board to do it together?
> 
> We are sort of damned if you do and damned if you don’t. But certainly we
> want to endure that progress can be made without losing the will to 
> contribute.
> 

Indeed. Putting things in one repo cannot scale and cannot be a solution
for something that is neither core pharo nor an application. I encourage
everyone who wants to get a good description of this problem to read 

"Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration
Management, and Product Data Management" by Peter van den Hamer & Kees
Lepoeter. 

With git and github a solution to decouple fast-moving from slow-moving
projects seems to be indeed to fork and make PRs. 
That only works if the quality of the PRs is high enough and we manage to
use the feedback from slower-moving projects well. 

Earlier, we’ve seen projects like Magma being overwhelmed by the number of
needed changes, and Pier being broken by Pillar not respecting its
constraints. 

With tools like Travis, it is quickly clear if a PR would result in a green
build in the original repo. 

With projects where Pharo uses only the core, and applications use more
than that, the applications still have a dependency problem: if the core
changes in Pharo influence the other parts, someone needs to do the work to
make those parts work again. With forked repos, that can be a pharo
maintainer, the project maintainer or the application maintainer. All three
need to be able to make those changes. And they need to be decoupled from
having to make them immediately. And being able to have the discussion
about the exact implementation independently from implementing a stop-gap
solution now is also valuable. 

So if Calypso is supposed to be extendable and only the core part is part
of Pharo, having it as an external project makes sense. With a fork for
Pharo to move at its own speed. If Iceberg is Pharo-only, just having
different branches for different Pharo versions, it sounds to me like it
might be better of in the Pharo project. Tonel is supposed to be
cross-platform so should be separate. 

Is this helpful?

Stephan

Re: [Pharo-dev] [Moose-dev] [cormas-dev] Pharo eye-candy: Domain-Specific Modeling and Simulation

[Stephan Eggermont]

Tudor Girba  wrote:
> Hi,
> 
> Bloc is a new world and the intention is to build a new stack on it. It
> can be embedded in Morphic, but not the other way around. Higher level
> frameworks, like Spec would have to build a renderer for Bloc.

Which of course doesn’t stop you from opening a morphic menu on a bloc
mouseclick. Here I open a ColorChooser

https://vimeo.com/236419682

Stephan

Re: [Pharo-dev] IMPORTANT: ML Etiquette

[Stephan Eggermont]

Tim Mackinnon  wrote:
> In a world of mobile phones, I think you have to accept top posting, it’s
> just too hard to work otherwise on a small screen ... that said, quoting
> a small piece to reply to - is doable, and I think we can all try to do that?

I strongly prefer ML-etiquette. 

> Sent from my iPhone

That supports NewsTap, which makes it easy to not top-post. I’m not sure
why lines are not broken though. 

Stephan

Re: [Pharo-dev] Beacon for Pharo 7

[Stephan Eggermont]

Norbert Hartl  wrote:
> How can pillar kill pier?

They can not both be loaded. Pillar should have just forked: copy and
rename the parts needed. 

Stephan

Re: [Pharo-dev] Beacon for Pharo 7

[Stephan Eggermont]

Esteban Lorenzano 
wrote:
. 
> 
> Pillar did not kill Pier. 
> Pier was killed by the fact that nobody is using it (then, there is few
> efforts to maintain it).
> which is sad, because Pier was/is very powerful… 
> 
No. Pillar killed Pier by breaking it unnecessarily. A lot of times. No
Pillar maintainer ever looked at our Pier builds and tried fixing things in
a compatible way, or committed a fix when they broke something. Pier is
stable and works just fine. It is infrastructure and nobody makes money
with it, so maintenance is never going to be high priority. 

If you take up responsibility for changing core, you make sure the higher
level still works. If you don’t want that, fork

Stephan

Re: [Pharo-dev] Beacon for Pharo 7

[Stephan Eggermont]

Denis Kudriashov 
wrote:
> If two entities needs separate versioning they should be in
separate
> repositories. Do you agree with this?

They don’t, and shouldn’t. 
That is the way Pillar killed Pier. No separate maintaining of core
constantly breaking users. 

Stephan

Re: [Pharo-dev] Beacon for Pharo 7

[Stephan Eggermont]

Tudor Girba  wrote:
> I do have a strong opinion about baselines: The baseline problem exists
> already at a significant scale and is not a local one. they are too
> costly to maintain now, and we need to build tools anyway to handle them
> cheaply. Without those tools we are confined to manual work, and
> optimizing design around manual work is not a good direction. So, trying
> to optimize one project is not particularly useful.

We can only start from where we are. I’m sure that better tools will help,
and pushing for things to be structured in a way that gives us more work
now makes it take longer to get those tools. 

Groups are at the moment essential to minimize manual work. 

Stephan

Re: [Pharo-dev] Beacon for Pharo 7

[Stephan Eggermont]

Denis Kudriashov <dionisi...@gmail.com>
wrote:
> 2018-05-25 20:03 GMT+03:00 Stephan Eggermont
<step...@stack.nl>:
> 
>> Denis Kudriashov <dionisi...@gmail.com>
>> wrote:
>>> 
>>> Because when you will fix or improve Beacon-SysLog you will probably do
>> not
>>> want to update Beacon-Core version which will force you to update Pharo
>>> (where SysLog is not loaded).
>> 
>> I seem to be missing something here. Why would you update the baseline for
>> that?
>> 
> 
> Question is not about baselines.
> Separate repositories for Core and loggers are required to version them
> separately.
> It will allow users to load Core version 1.1, SysLog version 2.0 and
> FileLogger 3.0.
> And it will allow maintainers improve these projects separately. As I was
> described the fix in SysLog will not require updating BeaconCore which is
> included in Pharo.

You do not have a use case for separate repos, but one for duplicates of
the same repo. You need that anyhow because your images depend on different
branches and versions. You might want to solve that by having only one
image responsible for source code management, and all others connecting to
that instead of using libgit directly. 

Stephan

Re: [Pharo-dev] Crash on GC garbageCollect

[Stephan Eggermont]

Esteban Lorenzano <esteba...@gmail.com>
wrote:
> 
> 
>> On 25 May 2018, at 23:48, Stephan Eggermont <step...@stack.nl> wrote:
>> 
>> Esteban Lorenzano <esteba...@gmail.com>
>> wrote:
>>> that’s because 6.1 images still comes with an old VM.
>>> I think I will backport the newer, but next week (testing time has passed, 
>>> I think).
>> 
>> You probably want to include the TLS fix from this week for Win7 so github
>> repos eork
> 
> no I do not want :)
> because in that case I will need to repeat the full cycle: 2 weeks as
> latest, one month as stable in 7.0, than backport.
> and probably in that moment there will be another fix to include. 

I understand that you don’t want, but releasing a stable vm for Pharo 6
where Iceberg (that is, github) doesn’t work on Win7 is also not really a
solution. 

Stephan

Re: [Pharo-dev] Crash on GC garbageCollect

[Stephan Eggermont]

Esteban Lorenzano 
wrote:
> that’s because 6.1 images still comes with an old VM.
> I think I will backport the newer, but next week (testing time has passed, I 
> think).

You probably want to include the TLS fix from this week for Win7 so github
repos eork

Stephan

Re: [Pharo-dev] Beacon for Pharo 7

[Stephan Eggermont]

Norbert Hartl  wrote:
> Really?? Don‘t you think the overhead is massive compared to the gain?

As long as the baselines are nice trees, described only one level deep, it
should be ok-ish. That never seems to be the case though, and as soon as
you get diamond dependency issues the duplication of volatile information
creates a lot of commit ripple

I’d would like to see a description of how that is supposed to work with
all the duplicated baselines and repos. 

Stephan

Re: [Pharo-dev] Beacon for Pharo 7

[Stephan Eggermont]

Denis Kudriashov 
wrote:
> 
> Because when you will fix or improve Beacon-SysLog you will probably do not
> want to update Beacon-Core version which will force you to update Pharo
> (where SysLog is not loaded).

I seem to be missing something here. Why would you update the baseline for
that? 

Stephan

Re: [Pharo-dev] Beacon for Pharo 7

[Stephan Eggermont]

Denis Kudriashov 
wrote:
> Hi.
> 
> I was looking at Beacon again to prepare integration. Some changes was
> needed in baseline for better granularity. So I send pull request because I
> have no permissions.
> 
> But now I remember that we had idea to integrate only core part of Beacon
> which requires MemoryLogger and TranscriptLogger. And we wanted to manage
> logger backends using separate baselines. So we need separate repos to have
> separate versioning.

Why would you want separate baselines for that? And on top of that separate
repos? 

Stephan

Re: [Pharo-dev] Pharo 7 on SqueakJS (demo)

[Stephan Eggermont]

Pavel Krivanek 
wrote:
> Hi,
> 
> with some tweaks mostly related to FFI and fonts, we are able to run Pharo
> 7 on SqueakJS VM.
> 
> Do not expect blazing performance. Currently, it is about two orders of
> magnitude slower than the native VM.
> 
> https://pavel-krivanek.github.io/pharo/pharo.html
> 
> Cheers,
> -- Pavel
> 
> 

Cool. It works on my phone. 

Stephan

Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7

[Stephan Eggermont]

Sean P. DeNigris  wrote:
> Tim Mackinnon wrote
>> Hi what does it mean “Iceberg does not manage yet upgrade of the local
>> clones”
> 
> This is most commonly encountered when one enables shared repository
> location in Iceberg.

And that also breaks when you need to work on different branches, so a
shared repository location is at the moment not a recommended setting?

Stephan

Re: [Pharo-dev] Esteban's ChangeLog week of 30 April 2018

[Stephan Eggermont]

 wrote:
> 
> This should provide backward compatibility on baselines (who can
> still be declared with +github://+ etc. protocol) and 
> makes tonel format available up to Pharo 3.0 versions (since it does
> not depends on iceberg presence anymore).

That is great! Thanks!

Stephan

Re: [Pharo-dev] Fwd: ByteArray>>at:put:

[Stephan Eggermont]

Sven Van Caekenberghe  wrote:
> 
> 
>> On 26 Apr 2018, at 15:21, Sean P. DeNigris
>>  wrote:
>> 
>> Relevant to Pharo?
>> 
>> From http://forum.world.st/ByteArray-at-put-tp4955848.html :
> 
> We don't (want to) mix binary and character collections or streams. Going
> from one to the other is called encoding and decoding, it has to be done
> while being conscious of which encoding you are using. Sending
> #asByteArray to a String or #asString to a ByteArray is dangerous, lazy
> and wrong (in most cases), especially in an international context.

How do we capture these kinds of decisions? This is crucial information for
people trying to migrate to Pharo. 

Stephan

Re: [Pharo-dev] Do we kill the catalog?

[Stephan Eggermont]

Thierry Goubier 
wrote:

>No

+1

> 
> Just write that ston now for the current state of OSProcess (with all 
> versions and platforms supported).
> 
> Or write that ston for a project that has stable branches for all pharo 
> versions, from say 1.3 to now.
> 
> But, in a way, please do the way you like, and, well, a few years down 
> the line, we're back at the same situation as now.
> 
> Not that I wish it, but I can see when someone is solving a problem with 
> yet another way of having the problem.

Indeed. 

Stephan

Re: [Pharo-dev] Do we kill the catalog?

[Stephan Eggermont]

Gabriel Cotelli  wrote:
> And please support the use of baselines. Nobody wants to also mantain a
> ConfigurationOf just for the catalog when using baselines.

That sounds like a non-problem. One file that never needs to change. Let’s
solve the problems first

Stephan

Re: [Pharo-dev] PharoDays: 14/15 June 2018

[Stephan Eggermont]

Stephane Ducasse <stepharo.s...@gmail.com>
wrote:
> Hi All
> 
> We would like to organise PharoDays the 14 and 15 June. Could you tell us
> if you see big problems from your side before we announce it.

Works better than 7/8, which I cannot make

Stephan Eggermont

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

Cyril Ferlicot D. <cyril.ferli...@gmail.com>
wrote:
> Le 19/03/2018 à 18:49, Stephan Eggermont a écrit :
>> Then why bother releasing?
>> 
> 
> Hi,
> 
> For people using Pharo 7 to not get the same bugs for more than 1 year,
> to get the new functionalities and to be able to detect new bugs
> introduced in releases.

Forgive me for sounding like a broken record. How exactly is this style of
releasing going to help with these points?

Stephan

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

Denis Kudriashov <dionisi...@gmail.com>
wrote:
> 2018-03-19 9:16 GMT+01:00 Stephan Eggermont
<step...@stack.nl>:
> 
>> Denis Kudriashov <dionisi...@gmail.com>
>> wrote:
>>> 2018-03-17 17:01 GMT+01:00 Stephan Eggermont
>> <step...@stack.nl>:
>>> 
>>>> Denis Kudriashov <dionisi...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> No. Each build just loads specified version. I do not need to create
>> new
>>>>> version for new build.
>>>>> But I think I still not understand you
>>>> 
>>>> That specified version will no longer work in a newer pharo build. Pharo
>>>> changes, making it necessary for your dependencies to change. Will you
>> make
>>>> a new release each time one of your dependencies needs to change?
>>>> 
>>> 
>>> I do not put dependencies of projects which are part of standard Pharo
>>> image. So Pharo updates do not affect my baselines
>> 
>> And your dependencies are not impacted by standard pharo changes?
>> 
> 
> It can be impacted of course. But it is normal process for alpha Pharo 7.
> And Pharo 6 is fixed, so I do not care.

Then why bother releasing?

Stephan

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

Denis Kudriashov <dionisi...@gmail.com>
wrote:
> 2018-03-17 17:01 GMT+01:00 Stephan Eggermont
<step...@stack.nl>:
> 
>> Denis Kudriashov <dionisi...@gmail.com>
>> wrote:
>>> 
>>> No. Each build just loads specified version. I do not need to create new
>>> version for new build.
>>> But I think I still not understand you
>> 
>> That specified version will no longer work in a newer pharo build. Pharo
>> changes, making it necessary for your dependencies to change. Will you make
>> a new release each time one of your dependencies needs to change?
>> 
> 
> I do not put dependencies of projects which are part of standard Pharo
> image. So Pharo updates do not affect my baselines

And your dependencies are not impacted by standard pharo changes?

Stephan

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

Denis Kudriashov 
wrote:
> 
> No. Each build just loads specified version. I do not need to create new
> version for new build.
> But I think I still not understand you

That specified version will no longer work in a newer pharo build. Pharo
changes, making it necessary for your dependencies to change. Will you make
a new release each time one of your dependencies needs to change?

Stephan

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

Denis Kudriashov <dionisi...@gmail.com>
wrote:
> 2018-03-17 13:15 GMT+01:00 Stephan Eggermont
<step...@stack.nl>:
> 
>> Denis Kudriashov <dionisi...@gmail.com>
>> wrote:
>> 
>>> So to get all minor fixes from all dependencies the code should be loaded
>>> from such floating branch (0.5.x). The main project can be locked to fix
>>> current version (only dependencies will be updated).
>>> And all released versions (0.5.3 tag) will be completely reproducible.
>>> 
>> 
>> So your goal for released versions is to be only loadable on a specific
>> pharo build?
>> 
>> 
> On any pharo build. I not understand what you mean

Your dependencies will need to be updated to run on newer pharo builds,
won’t they?

Stephan

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

Denis Kudriashov 
wrote:

> So to get all minor fixes from all dependencies the code should be loaded
> from such floating branch (0.5.x). The main project can be locked to fix
> current version (only dependencies will be updated).
> And all released versions (0.5.3 tag) will be completely reproducible.
>

So your goal for released versions is to be only loadable on a specific
pharo build?

Stephan

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

[Stephan Eggermont]

Marcus Denker  wrote:
>> On 9 Mar 2018, at 23:34, Torsten Bergmann  wrote:
>> 
>> Additional portable versions would be nice too (based on a simple ZIP)
>> instead of only the installable apps
>> 
> 
> Is there a deeper reason for this? If I look at “other systems”, they
> manage to have *one* download, *one* way of installing.
> For me, offering *a lot* of possible different ways means that the user
> has to choose without knowing why there is even the option to choose…

Yes. I want the live usb stick experience

Stephan

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

Denis Kudriashov 
wrote:
> 
> It is clear that we need both baselines for that case.
> But because we will move Calypso to Pharo repo I think it is easy to manage
> strong versions directly in Pharo loading script for now (in #loadCalypso
> method).

Easy for now, yes. And also a bad example for others to follow. And
something that doesn't scale. Where is the increased modularity going to
come from if we still manage everything as a monorepo?

Stephan

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

Guillermo Polito 
wrote:
>...
> 
> So yes, it may block upgrades, but until we have tools that allow us to
> cope with the complexity, I prefer to have reproducible versions where I
> can reproduce bugs in a reproducible way than an unpredictable version
> where I cannot grasp the cause of a problem :/.

I strongly advice against using Baselines for that. They are supposed to be
edited from hand, and using them for reproducible versions will break other
projects, as we've seen earlier with Configurations. AFAIK Metacello can
register which versions were loaded in which order, so that information
should be recorded for reproducibility. 

Stephan 

Re: [Pharo-dev] Released versions in Pharo Bootstrap

[Stephan Eggermont]

teso...@gmail.com
<teso...@gmail.com> wrote:
> Hello,
>  i have seen in the latest version of Pharo baselines pointing to
> "floating" versions. A version that is not fixed. I want to know why this
> is like that?

Because that is the way it should be? It is hand-edited, so repeatable
builds are not the goal, just working software. Repeatable builds come from
recording what you loaded in what order. Repeatable builds with fixed
dependency versions don't help you with working software, as they block
your dependencies from getting patched. Never depend on hard-coded versions
of anything you don't control yourself. See the 5D paper

Stephan Eggermont

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

[Stephan Eggermont]

Sean P. DeNigris  wrote:
> Or are you saying there should be a collection of rewrite rules even after
> the method is totally removed so one can bring a very old project up to the
> newest APIs?

Making sure the code works in each intermediate version of Pharo is
increasingly unattractive. It also requires indefinite support of all the
old pharo versions. A collection of separate rewrite rules looks to me like
the right thing to both explain changes and speed up migrations. 

Stephan

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

[Stephan Eggermont]

Sven Van Caekenberghe  wrote:

> Either we keep on adding cruft (or leaving cruft in place) in the sake of
> backwards compatibility or be do something about it. It is not hard to
> fix a couple of senders. It could be done more softly with a deprecation.
> 
> Cleanups at the level of Object are particularly valuable.

It needs to be done in a way that is sustainable. That means with a code
rewrite rule. Deprecations are not enough. The number of people who can
migrate forwards older code is very small, especially as we are missing
crucial parts of design discussion that took place on slack and were not
copied to mail. 

When I created my Morphic screencasts I had to look back to mailing list
discussions from 10 years ago and had to run ancient squeak images to gain
an understanding of how things were supposed to work and how they changed. 

Cleanups at this low level need to be done with rewrite rules (and tests)

Stephan

Re: [Pharo-dev] Problem to save packages

[Stephan Eggermont]

Nicolas Cellier
 wrote:

> These are my files, I want to be in control and manage them by myself.
> Eventually save them on another medium, and not mix them with thousands of
> other files that generally populate a package-cache.
> Do you see what I mean?

Two aspects:
1 It sounds like you have a shared package cache for all your images? That
is somewhat incompatible with the current tooling, especially with regard
to reproducible loading of Metacello configurations. Having lots of
duplicated mcz's in each image's package cache is wasteful
2 Yes, having much more control over the package cache makes sense,
especially with TelePharo. Different scenario's need different strategies.
Mixing new, own code with loaded frameworks is not very practical

Stephan

Re: [Pharo-dev] Problem to save packages

[Stephan Eggermont]

Nicolas Cellier
 wrote:
> But whatever the bug, why saving in the package-cache?
> The package-cache is just a cache as the name tells.
> It's less volatile than RAM, but can still be subject to aggressive cleanup.

Because it is much more reliable than network, and it depends on simpler
and working infrastructure. The package cache is deliberately not cleaned,
and not shared by default. 

Stephan

Re: [Pharo-dev] [ANN] Next Pharo release moved to end of year

[Stephan Eggermont]

Esteban Lorenzano 
wrote:
> Hi all, 
> 
> After some analysis of current condition of development, we decided to
> move the upcoming release to end of the year (and not May, as usual). 

Thanks for the clear and timely decision. Having to delay is never nice,
but with a high innovation rate comes a higher risk. Denial helps noone,
keep up the good work!

Stephan

Re: [Pharo-dev] [IMPORTANT] PHARO CONTRIBUTION PROCESS UPDATED! PLEASE READ!

[Stephan Eggermont]

Luke Gorrie  wrote:

> For me it's another story. I'm on an unsupported platform (NixOS Linux),
> I'm building the VM from random git commits because the source releases are
> all antiquated, Iceberg segfaults the moment I start it, and
> epica+monticello+metacello+iceberg+fogbugz+jenkins feels like a series of
> obstacles between me and maintaining my application.

Isn't nix supported by travis? I suppose that means that you should be able
to automatically build a variant of opensmalltalk
I have absolutely no idea how much work that would be though. 

Stephan

Re: [Pharo-dev] Blame support P7

[Stephan Eggermont]

Sven Van Caekenberghe  wrote:

> (1) what non-trivial code is actively maintained from a single code base
> between Pharo, Squeak and Cuis ?

That is nice, but too limited a question

What about the need to maintain non-trivial large code bases between
multiple smalltalks? If we only limit ourselves to open source, just look
at Glorp and PDFTalk. 

Stephan

Re: [Pharo-dev] Blame support P7

[Stephan Eggermont]

Eliot Miranda 
wrote:
> Hi Stephan,

> Then why on /earth/ would one stop using Smalltalk in /the most central
> part/ of the collaborative programming process, version control?  

Because of the underestimation of the work needed, vs. the advantage of
eliminating one barrier to entry. One of the differences in perspective is
that Stef sees lots of people new to smalltalk (students) and needs them to
get up to speed really fast. The collaboration needs there are different
from yours, where you need to deal with long-term collaboration mostly
between experts. 

There is also a significant underestimation of the complexity of version
control, and the need to support different workflows. The community members
having experience managing complex workflows don't manage to explain well
enough what they need. 

Stephan

Re: [Pharo-dev] Blame support P7

[Stephan Eggermont]

Eliot Miranda 
wrote:
> Isn't it important to preserve the ability to exchange code
between Pharo,
> Squeak and Cuis?  Don't you care that the VM development is directly
> affected by this?  Is the VM and plugin support not important to Pharo?

Git support turns out to be much more work than we hoped and expected. Too
many library updates needed, support for different workflows and platforms,
switch to file per class. The Iceberg channel on Discord is one of the
busiest channels. 

Stephan

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

[Stephan Eggermont]

Esteban Lorenzano 
wrote:
> Hi everybody, 
> 
> This looks like a good moment of the year to ask all of you what would
> you want to see in Pharo next year. 

I wish you all the time and good health to realize some of your Pharo
dreams

Stephan

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

[Stephan Eggermont]

Denis Kudriashov 
wrote:
> Hi Bernhard.
> 
> The deprecation is still in progress.

Considering the amount of non-image code using this, I would be interested
to hear how this is going to be supported and documented. 

Stephan

Re: [Pharo-dev] create snapshots out of github based packages

[Stephan Eggermont]

Op 10-12-2017 om 15:44 schreef Cyril Ferlicot:

On dim. 10 déc. 2017 at 15:07, Nicolai Hess 

Re: [Pharo-dev] [ANN] Willow 4.0.0 released!

[Stephan Eggermont]

Op 16-11-2017 om 15:44 schreef Gabriel Cotelli:

Hi,

We're happy to announce the general availability of Willow and it's 
related projects in the Web Stack ecosystem hosted at 
https://github.com/ba-st/.


Willow is a Web Interaction Library that eases the burden of creating 
AJAX-based web applications. The project goals are:


Interesting approach. Might be useful to use as a target for 
(QC)Magritte. So much things to try out, and not enough time!


Stephan

Re: [Pharo-dev] Stuck trying to contribute

[Stephan Eggermont]

Is all this summarized on Guille's (and Thorstens) pages?

Stephan

Re: [Pharo-dev] Iceberg Default Subdirectory Setting?

[Stephan Eggermont]

On 20/09/17 23:50, Sean P. DeNigris wrote:

I always put my packages in gitroot/repository per instructions I read when I
was starting with FT (Dale's IIRC). It's a (minor) drag to type that every
time I add a local git repo. How would y'all feel about a setting?


Is that shared with multiple images? How do you deal with needing 
different branches of the same repo?


Stephan

Re: [Pharo-dev] Iceberg

[Stephan Eggermont]

On 19/09/17 17:52, Marcus Denker wrote:

I personally find it very confusing that http://files.pharo.org/vm/ does 
not have the current

VMs…


Now I am confused. The date seems to suggest they are current? At least 
on Linux


Stephan

Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?

[Stephan Eggermont]

Frank wrote:
> I feel sorry for you if you really have not yet understood that proper, early 
> and complete documentation and comments ARE ONLY an investment in the code, 
> because they save time and efforts later on, which always pay back - mostly 
> multiple times. 

Perhaps you might want to explain to me the return on investment of the Orca 
documentation then? Zero users, zero return on investment. 

I feel annoyed if you talk in absolutes like that, because I know that there 
are lots of situations where creating documentation is a waste of effort. And I 
have also been bitten by lack of documentation. And I have even been in a 
situation where both happened at the same time, where a lot of effort was put 
in creating the wrong kind of documentation. Oh, and I even wrote a bit of 
documentation myself. 

I have been thought many things at university, and there were many more things 
I had to learn in industry. And from open source projects, which have other 
things to teach. 

Investing means making decisions. Fully documented non-working code has no 
value. Working code that no-one can use neither. 

Your current communication is manipulative: you try to put yourself in a 
dominant position by using absolutes, saying you feel sorry for me, and 
bragging about your experience. That annoys me. If you want to convince me, use 
arguments. 

Stephan

https://en.m.wikipedia.org/wiki/Nonviolent_Communication

Re: [Pharo-dev] Anybody using Orca Smalltalk to JavaScript?

[Stephan Eggermont]

Hi Frank,

It must be very frustrating to see so many possibly interesting projects that 
are so difficult to get started with, being it because of lack of development 
and migration to the latest versions, or because of lack of documentation. It 
is a feeling I, and no doubt a lot of other smalltalkers, share. 

Our open source community consist of people spending a lot of their time on 
Pharo. A few of them are paid to do so, some more make it their bachelor, 
master or PhD project, and for even more it is just a hobby or side project. 
They all have different objectives with their projects, and different 
constraints. 

To get good results with our community, effective communications is essential. 
That allows us to develop multiple projects in a way that creates synergy, and 
a coherent whole. 

I find a crucial element of effective communication is to build up a 
connection, so others are able to hear your message. Your first message in this 
thread is excellent. 

Telling people they are not professional, and do a bad job, without knowing 
about the context in which the code was produced, is unlikely to lead to 
effective communications. People who feel attacked are no longer open to your 
message, irrespective of the contents. 

Effective communications has also nothing to do with PC or 'truth', and 
especially not the absolute and blaming kind. Posing opinions as truths looks 
less than helpful to me. I find clearly separating facts, feelings, needs, and 
strategies to fulfill those needs more effective. 

Creating documentation takes time and effort. That needs to be balanced against 
other priorities. You might not like the priorities others set, but you are not 
paying (in money nor effort). Also, we can only start at the position we are 
now in, no matter how much we want to be somewhere else. 

This is open source, so please let us know where you want to contribute so we 
can help you getting started. 

Stephan

Re: [Pharo-dev] Impediment to contributing

[Stephan Eggermont]

On 10/08/17 17:16, Guillermo Polito wrote:

I've made some write up for the pharo part (not metacello or external
projects)

https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo

Of course, expect bugs on it :) Not everything is smooth. If you have
comments, they are welcome.


Thanks Guille.

Stephan

Re: [Pharo-dev] About cr and lf

[Stephan Eggermont]

On 06/08/17 15:25, Peter Uhnak wrote:

Hi,

that's why one of the proposals was to configure the stream to either use 
always specific line endings

stream beForWindows.
stream newLine. "outputs CRLF irrespective of where the image is currently 
running"

and

stream beForCurrentPlatform.
stream newLine. "returns whatever it is currently running on"


Hmm. I'm pretty sure it should not be a stream responsibility.
What about the encoder?

Stephan

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

[Stephan Eggermont]

On 27/06/17 14:56, Sven Van Caekenberghe wrote:

P3 is a modern, lean and mean PostgreSQL client for Pharo.


Nice! Thank you

Stephan

Re: [Pharo-dev] Recursively downloading Pharo packages / Building images with Nix

[Stephan Eggermont]

On 23/06/17 17:59, Luke Gorrie wrote:

Hi again Ben,

I have an idea for a hacky way to import all of the Pharo packages into
my universe. Shooting holes in this idea would be welcome :).


...


Sane? Workable? Fatal flaws?


You might want to look at StephanEggermont/DeprecationFinder on sth
That tries downloading latest versions of all packages in all projects 
of sth. It misses the team projects. It needs an old moose (or 
upgrading). Another experiment I did was 
StephanEggermont/MonticelloProjects. That combines all code from all the 
mcz's in a project and can recreate the separate versions. The 
deduplication is incorrect when there are inconsistent histories.


http://forum.world.st/Compact-representation-of-source-code-history-td4866993.html
http://forum.world.st/Working-with-a-compressed-Fuel-file-td4869105.html#a4869318

Stephan

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

[Stephan Eggermont]

On 02/06/17 23:10, Nicolas Cellier wrote:

This is now fixed, you just have to wait for appveyor to finish its job.
Guys, I have pushed Win64 VM including the Pharo flavour.


Thanks, I appreciate it.


It works well in Squeak but I'm not a Pharo user (or very casual).
All I'm asking for weeks or even months is a little feedback...
So this evening, when I see that the 64 bits image does not even start
and that I got absolutely no feedback except this late one of Henrik
(Thank you thank you thank you Henrik), I feel sad.
Helping Pharo is not very rewarding :(


I'll take a look at work tomorrow.

Stephan

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

[Stephan Eggermont]

On 06/06/17 17:11, Esteban Lorenzano wrote:

Dear World,

The time has come for Pharo 6.0!


Yes! Well done!

Stephan

Re: [Pharo-dev] FTs now support single and multi-cells selection

[Stephan Eggermont]

Nice. That looks like we are getting ready to add inline editable 
table-based views to our browsers. That should work well with Cucumber 
style tests with examples.


Stephan

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

[Stephan Eggermont]

At the PharoDays I was painfully reminded that SSDs perform really badly when 
using small files. The Bloc tutorial used a github filetree repo and that has a 
lot of files. The whole folder is 116 MB in 16K files. Copying that amount of 
data should not be noticable, taking about a third of a second. With it being 
in so many files, it took more than half a minute, or a hundred times as long. 

That is too much overhead. How can we improve the file format in a way that 
keeps the cross-platform exchange advantages and a reasonable way to view diffs 
and propose small changes using the github web tools? 

Cuis uses a different format with git. How does that compare? What is used in 
Squeak?

Stephan

Re: [Pharo-dev] Anyone meeting up night before Pharo Days (17th?)

[Stephan Eggermont]

On 06/05/17 12:58, Tim Mackinnon wrote:

Hi guys - I managed to get a “weeknight pass” so that I can come to
Pharo days and try and catch up with all the progress you have made.

I’m taking a Eurostar on Wed night (17th) and wondering if anyone is
meeting up the night before on the 17th? I don’t arrive until 8:30 -
but maybe some of you are having some post supper drinks somewhere?


Yes, good idea. I'll arrive with a TGV from CDG at 21:11


I have booked a hotel near the venue, but I’m thinking that I may
change it, to somewhere in town as I think it might make more sense
as I’m sure folks may end up eating in town anyway.


I haven't booked a hotel yet. I'll go for in-town.

Stephan

Re: [Pharo-dev] Smalltalk Internet Browser

[Stephan Eggermont]

On 29/04/17 04:11, askoh wrote:

Being connected to the internet is going to be a necessity for any piece of
software in the immediate future. So every Smalltalk development environment
or application should have that capability as default. To push that envelop,
every image should have a Smalltalk native Internet Browser.


Web is a very bad platform from an engineering point of view. The amount 
of accidental complexity is astounding, as is the number of useless 
layers obfuscating this all. I don't think we are ready to waste the 
amount of engineering needed to do something useful at the browser 
implementation side of the web (except for things like amber, pharojs 
and squeakjs).


Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 21/04/17 15:22, Dimitris Chloupis wrote:

its ironic you say this Stephan

and the irony is that you claim that Dark Theme is inappropriate because
Pharo uses so many hard coded colours when it was Esteban's effort to
have a dark theme that decreased the amount of hard coded methods and
modified them to support themes.  The very reason you use that Dark
Theme should not be used as default is the very reason to use it because
it will forces us to detect those methods and convert them to support
our Theme classes. This will not only improve the Dark Themes but ANY
future theme.


No. That is just an indicator that we are far from finished, and that is 
one good reason not to switch to it close to release. The other reasons are:

- it breaks our own feature freeze rule;
- giving us not enough time to test;
- the number of hard-coded colors suggests that our practical 
(non-automated) test coverage is low and the actual users of dark theme 
have usage patterns that miss parts of the system;
- it focuses attention on a part of the system that should be irrelevant 
so close to release;

- it forces projects that depend on pharo to make changes now;
- making it more difficult for them to release close after pharo releases;
- and thus makes pharo release management look amateurish;
- it is a bad default for the majority of users;
- who will mostly not do any testing but only switch to light theme as 
fast as possible, especially when confronted with a decision made like this;

- and is thus bad marketing;
- it is taking a lot of time from the people who should be doing more 
productive things.


Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 21/04/17 13:26, Dimitris Chloupis wrote:



On Fri, Apr 21, 2017 at 1:53 PM Ben Coman
> wrote:

On Fri, Apr 21, 2017 at 4:10 PM, Dimitris Chloupis
> wrote:
> You know what amazes me about this discussion ?
>
> not one even bothered posting
> a single screenshot demonstration all these "problems" , just one .

To rebut you, you haven't been paying attention :)  :P

https://pharo.fogbugz.com/f/cases/19941/Dark-Theme-overlapped-title-bars-need-to-be-distinctive

cheers -ben


I mean in this thread , will make it easier, because for example fogbuz
asks for a login.


You still haven't been paying attention. We have hard-coded colors all 
over the place. And I am not interested in new bug reports now. I want 
the theme switch reverted and done after the release. This is just bad 
process and it should be stopped.


Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 16/04/17 23:27, Cyril Ferlicot D. wrote:

On 16/04/2017 23:13, Stephan Eggermont wrote:

We do not break things a week before the release. We break them a week
after the release. Otherwise, why bother.

Stephan



As I asked in my previous mail, what is broken?


There are 214 instances of the text 'Color white' and 210 of
'Color black' in a 60450 image. Moose images have 1.5 to 2 as many

Stephan

Re: [Pharo-dev] Remove all Configurations in the Pharo 6 release?

[Stephan Eggermont]

On 16/04/17 16:14, Dimitris Chloupis wrote:

Just for the record the easiest way to load packages in the image the
Package Browser relies solely on configurations . Is there a plan to
migrate because as much I am vocal supporter of Pharo moving to git it
will be a big lose if Package Browser is not ported .


Which browser do you mean? Catalog? That generally does not work well 
because it cannot deal with combinations of configurations.


Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 16/04/17 20:53, Cyril Ferlicot D. wrote:

Also, I use the dark theme since almost two years and I don't remember
having problems. Do you have examples?


Within two minutes I found a non-themed visualization in Moose.
The switching works a lot better than last time I looked at dark theme.

Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 16/04/17 20:53, Cyril Ferlicot D. wrote:

And last, when a new version of a programming language is out, we do not
expect all applications to be up to date with the language at the time
of the release.


We do not break things a week before the release. We break them a week 
after the release. Otherwise, why bother.


Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 15/04/17 16:02, Norbert Hartl wrote:

And comparing the capability of building
contrasts with colors, dark colors win, sorry. At least that were the
last researches I've read.


Which ones? https://webstandards.hhs.gov/guidelines/106 seems pretty
clear.

Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 15/04/17 14:43, p...@highoctane.be wrote:

Make it default so that it will bother people enough to fix the glitches.


That is fine to do for half a year starting with Pharo 7.
I'm all in favor of making changes in development that help
us improve. It is definitely not a good idea to make sure that
no external project looks good at the release of Pharo 6,
and make life worse for 80% of developers. Released version needs
to be a light theme. In development we can switch for a while

Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 15/04/17 13:48, Sven Van Caekenberghe wrote:

It is a matter of taste, of course, but after 5 major releases with White 
Themes, an alternative is more than welcome.


Mostly because it is not a matter of taste. For most people (there are 
several eye problems where it is not the case), a dark on light theme is 
better. The exceptions are well known (keeping night vision, photo/video 
processing, a room that is too dark), but there is no reason at all to 
make a dark theme default


Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 15/04/17 10:19, Dimitris Chloupis wrote:

I am a huge supporter of Dark Themes, they are friendlier to the health
of the eye and much friendlier to the environment too. Their objective
value cannot be questioned. But as always personal taste plays a role here.


All science shows otherwise.

Stephan

Re: [Pharo-dev] changing default theme to DarkTheme

[Stephan Eggermont]

On 14/04/17 09:09, Esteban Lorenzano wrote:

I wanted to let you know that we talked at the board and we want to make the 
DarkTheme a default for Pharo 6.0.
This is just because we want to have a visual immediate reference of changing 
things (yeah, marketing ;) )



No. Please revert that decision. It is too late. You can try that for 7, 
and then have the discussions, but not for 6.


Stephan