Re: [Pharo-dev] [ANN] The STON Specification, Cog speed, and namespaces/modules

[Shaping]

Hi Eliot.

Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to VW's 
Double. In 64-bit SmallFloat64 maps exactly to SmallDouble. But I wonder 
whether there is any issue here.  STON would use the print strings for (PSC) 
Float / (VW) Double, and so deseerialization on Pharo would automatically 
produce the right class.  Going in the other direction might need some help.  
APF needs support in PSC before one can port, but are representable as 
suitably-sized word arrays.

 

There is no support for __float128 anywhere in the VM (e.g. not even in the 
FFI) on PSC as yet.

 

I see Pharo’s WordArray.  I’ll work on an APF for Pharo, as time permits.  I’m 
using APFs in VW in the 300-bit range, and want to reduce the needed precision 
to 64 bits, to save space and time on large (5 million+) scalar time-series, 
both on the heap and during BOSSing (25 m save-time now).   The problem is not  
so much an issue for the JulianDayNumber (JDN)-precision, which is adequate in 
this app at 14 to 15 digits (even though my JDN class subclasses APF, for now). 
 Other calculations need the more extreme precision.  I think I can make 
128-bit floats work, and would really like to see a small, fast, boxed 128-bit 
float implementation in Pharo or VW.   The APFs are big and slow.  Where in the 
queue of planned improvements to Pharo does such a task lie?  I suspect it’s 
not a very popular item.

 

Broadening the issue somewhat, I’m trying to find as many good reasons as 
possible to justify the work needed to port all my VW stuff to Pharo.  

 

I’ve seen the references to Cog’s speed and coming speed-up.  Are there recent 
(say, in the last year) benchmarks comparing VW and Pharo?   Any details here 
would be very much appreciated.

 

Having no namespaces in Pharo is, I think, the biggest impediment.   I prefer 
not to prefix class names, but there may be fewer name-collisions than I 
suppose--maybe none.   Still, I need to know how VW and Pharo classes map in 
order to place overrides and extensions correctly.  Besides the mentioned 
float-class mappings is there a reference on this?

 

Object allSubclasses 

 

in Pharo 7 64-bit, produces 14946 classes.  Pharo is a little bigger than it 
used to be.

 

I suppose I don’t need to check all unloaded packages because all classes in 
each of those will have the same unique prefix. Is that correct?  Or, I could 
just load every package I can find, before I check names.  But that little 
experiment has never gone well in the past.

 

Is the Pharo-with-namespaces issue dead or merely suspended, awaiting a more 
fitting idea than what VW currently offers? 

 

 

Shaping

 

 

On Tue, Nov 6, 2018 at 12:56 AM Shaping mailto:shap...@uurda.org> > wrote:

STON is able to serialise Pharo’s Floats, what do you mean by double ?

 

Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, with 
a range between =10^307 and 10^307.

 

Additionally, I recently asked Sven if t would be possible to store 
ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) 
without loss of precision.

 

I’m referring to VW’s Double (and SmallDouble in 64-bit engines/images).  APFs 
are binary representations that can be arbitrarily large, using Integers 
(LargePositiveIntegers for example) to model the bits of the mantissa.

 

Before, because STON extends JSON, it was storing all kind of numbers either as 
float or integer.

 

Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of 
precision through serialisation as float, what was done before).

 

But I do not know if this change is integrated in recent images yet.

 

…..

 

Number subclass: #Float

instanceVariableNames: ''

classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 MaxVal 
MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi RadiansPerDegree 
Sqrt2 ThreePi Twopi'

poolDictionaries: ''

category: 'Kernel-Numbers'

 

 

My instances represent IEEE-754 floating-point double-precision numbers.  They 
have about 16 digits of accuracy and their range is between plus and minus 
10^307. Some valid examples are:



8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12

….

 

I see that Pharo’s Float is VW’s Double.   So then I just need to be able to 
serialize APF.

 

….

FIFloatType subclass: #FFIFloat128

instanceVariableNames: ''

classVariableNames: ''

poolDictionaries: ''

category: 'UnifiedFFI-Types'

 

 

I'm a 128bits (cuadruple precision) float. 

It is usually not used, but some compiler modes support it (__float128 in gcc)

 

THIS IS NOT YET SUPPORTED

….

 

The class above is also from the Pharo 7 image.  This is the largest of the 
c-type FFIFloats.  Any Float classes of this size and larger for the Smalltalk 
heap on 64-bit Pharo?  

 

 

Cheers,

 

Shaping

 

 

Le 6 

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

[Tim Mackinnon]

It’s a tricky trade off as Norbert alludes too - in my recent example I needed 
some underlying base pieces in place (for the compiler’s ast) and those needed 
reviewing to then be committed - then there were two parts to Calypso that 
relied on those changes) that also needed reviewing and I wasn’t sure if Denis 
waited for the core approval or loaded up my PR - but anyway it took him a bit 
of time to process that and he came back with some better suggestions that I 
also needed to implement (which I had to find time to do as well).

When I noticed that the core Pharo pieces were merged, I then had to chase 
Denis to see if he was now happy and could merge my changes.

I guess it would be helpful if there was a way to easily load up multiple 
project pr’s in one go (like the suggested slice concept) so maintainers can 
easily review.  Probably more importantly is an easy way to track the status of 
multiple submissions so you can follow up with relevant people and push things 
along and also ensure things get committed in the right order (eg doc the 
dependency chain a bit better).

For me, after a few days I forgot about my Calypso changes and realised a few 
weeks later (by accident) and so could chase Denis.

I think it’s this latter case that Steph alludes to - you lose interest after a 
few days without some useful prompts and easy status tracking. If we can make 
that easier I think it would help.

Tim

Sent from my iPhone

> On 7 Nov 2018, at 05:48, Ben Coman  wrote:
> 
> I get the feeling what is needed is mirroring all dependent repos from
> the canonical location under http://github.com/pharo-project
> and a Slice-like tool (probably keeping the name "Slice") which...
> 1. Pulls all dependent repos to the local machine
> 2. Simultaneously commits to the local repos with the same commit message
> 3. Updates a bootstrap-configuration file holding commit-hashes of all
> the dependencies and commits with same commit message
> 4. Pushes that bootstrap-configuration file and all changed dependent
> repos to user's github account
> 5. Issues a pull request for the bootstrap-configuration file
> 6. Our CI then builds a test-image by commit-hash direct from each
> user's repo and if it passes, pulls dependent repo commits under
> pharo-project
> 7. CI can then issue PRs to the dependency canonical repos
> 
> cheers -ben
> 
>> On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse  
>> wrote:
>> 
>> Calypso is integral part of Pharo as Iceberg.
>> We started to discuss the problem in the team. Right now this project
>> spread kills us.
>> 
>> Stef
>>> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont  wrote:
>>> 
>>> 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 

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

[Norbert Hartl]

> Am 06.11.2018 um 19:54 schrieb Stephane Ducasse :
> 
> Calypso is integral part of Pharo as Iceberg.
> We started to discuss the problem in the team. Right now this project
> spread kills us.
> 
It is not an easy decision. Either you bind everything closely to you and ease 
your workflow but have to do everything on your own. Or you welcome external 
projects not done by you and you enter modern dependency hell. Choose wisely or 
just try to solve the real problem. You neither have the time to develop 
everything by yourself nor have the patience to spend time on dependencies.

Norbert
> Stef
>> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont  wrote:
>> 
>> 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] Cannot use Zinc in Pharo7 anymore

[Ben Coman]

I get the feeling what is needed is mirroring all dependent repos from
the canonical location under http://github.com/pharo-project
and a Slice-like tool (probably keeping the name "Slice") which...
1. Pulls all dependent repos to the local machine
2. Simultaneously commits to the local repos with the same commit message
3. Updates a bootstrap-configuration file holding commit-hashes of all
the dependencies and commits with same commit message
4. Pushes that bootstrap-configuration file and all changed dependent
repos to user's github account
5. Issues a pull request for the bootstrap-configuration file
6. Our CI then builds a test-image by commit-hash direct from each
user's repo and if it passes, pulls dependent repo commits under
pharo-project
7. CI can then issue PRs to the dependency canonical repos

cheers -ben

On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse  wrote:
>
> Calypso is integral part of Pharo as Iceberg.
> We started to discuss the problem in the team. Right now this project
> spread kills us.
>
> Stef
> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont  wrote:
> >
> > 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] Porting from VW to Pharo

[Davide Grandi]

Do you have name collisions among your namespaces, now ?
If not ... problem solved, otherwise maybe you could refactor the 
classes clashing.

Or, maybe, I'm missing some points.

    Davide Grandi

On 06/11/18 07:23, Shaping wrote:
Can someone point me to the best tools for porting from VW 7.10 to 
Pharo 7 64-bit (or maybe 6.1)?


I'm not sure what to do about the namespaces. I realize that VW's 
namespace solution is just a good hack and that the true nature of the 
problem runs much deeper--but it does a good job of avoiding 
class-name collisions, which is mostly what I need it for, and I can 
control exactly how imports work.


Any suggestions are welcome.

Thanks.

Shaping


--
Ing. Davide Grandi
email  : davide.gra...@mclink.it
mobile : +39 339 7468 778

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

[Chris Muller]

> 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.

 - Chris

Re: [Pharo-dev] [ANN] Pharo v7.0.0-rc1 released!

[Esteban Maringolo]

http://files.pharo.org/image/70/ ?

Shouldn't this "unstable", "preview" or whatever you want to call it listed
somewhere?

In the web the link for files server is listed in the "Older versions" link.

Regards,

Esteban A. Maringolo


El mar., 6 nov. 2018 a las 16:00, Stephane Ducasse ()
escribió:

> Where can we download it? because I would like to add it to the blog post.
>
> Stef
> On Mon, Nov 5, 2018 at 4:12 PM Esteban Lorenzano 
> wrote:
> >
> > Greetings!
> >
> > I’m announcing today we reach Pharo 7.0.0-rc1!
> >
> > This is the first step to release a definitive version, and while we
> will continue integrating bug fixes, API change Pull Requests will be
> delayed until the open of Pharo 8.0.0 development.
> > Now, you would wonder what is the ChangeLog of this release… and answer
> is we still do not have one (btw, we should find a way to automate this).
> >
> > Anyway… we are very close to release now :)
> >
> > Please download, test, report issues.
> >
> > Esteban
>
>

Re: [Pharo-dev] [ANN] Pharo v7.0.0-rc1 released!

[Stephane Ducasse]

Where can we download it? because I would like to add it to the blog post.

Stef
On Mon, Nov 5, 2018 at 4:12 PM Esteban Lorenzano  wrote:
>
> Greetings!
>
> I’m announcing today we reach Pharo 7.0.0-rc1!
>
> This is the first step to release a definitive version, and while we will 
> continue integrating bug fixes, API change Pull Requests will be delayed 
> until the open of Pharo 8.0.0 development.
> Now, you would wonder what is the ChangeLog of this release… and answer is we 
> still do not have one (btw, we should find a way to automate this).
>
> Anyway… we are very close to release now :)
>
> Please download, test, report issues.
>
> Esteban

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

[Stephane Ducasse]

Calypso is integral part of Pharo as Iceberg.
We started to discuss the problem in the team. Right now this project
spread kills us.

Stef
On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont  wrote:
>
> 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] Cannot use Zinc in Pharo7 anymore

[Stephane Ducasse]

My problem is that this is a trivial change and I could fix everything
in 2 min. Now I cannot.
On Sun, Nov 4, 2018 at 11:43 PM Sven Van Caekenberghe  wrote:
>
> I think we all want the same thing: being able to move quickly. It is just 
> not clear how to do that.
>
> I saw that you tried a complex scenario in 
> https://pharo.manuscript.com/f/cases/22626/Should-not-hardcode-CmdCommandAborted
>  - I would not even known how to do that, I think.
>
> > On 4 Nov 2018, at 15:35, Stephane Ducasse  wrote:
> >
> > Just to share my pain with you. Try to change something in the API of 
> > Commander?
> > I think that it will be nearly impossible.
> > Because Iceberg/Calypso depend on Commander and they are all managed
> > in different repositories.
> > So it means
> > - fork each
> > - probably introduce automatic deprecation
> > - do a PR for each of the subprojects (it means identify for each one
> > if we should work on dev or master and being able to checkout
> > the correct version which is not always possible)
> > - then waits.that may be each of the PR got integrated
> > - now you lost total focus
> > - if one day you recover what you were doing then and only then you
> > may finish your change.
> >
> > Good luck.
> >
> > So to me the message is clear: stay away.
> > And this is what I'm doing.
> > We are damaging our agility on the altar of a pseudo modularity.
> >
> > So this is why I will focus on my tiny, uninteresting side projects.
> > Stef
> > On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse  
> > wrote:
> >>
> >> Hi Sven
> >>
> >> I agree with you. Ideally we would like to have much better tooling
> >> and process.
> >> Now the last time we discussed with Guille and Pablo about it: they
> >> estimated that this is over one year of work.
> >> And right now we do not have this engineering time to invest on this
> >> because other fronts need to be addressed.
> >> Still this is really slowing us. This is simple: I stopped thinking to
> >> improve something that touches external packages.
> >> So I will not work on the trivial changes that would improve 
> >> Calypso/Iceberg.
> >> Why? Because this is tedious, boring, not rewarding.
> >> So yes we can do easily with iceberg simple fix on not external
> >> packages but as soon as
> >> - you need to load latest dev version (which can be a different one
> >> than the current one)
> >> - update your repo
> >> - fix
> >> - do a PR
> >> -  wait for its integration
> >>
> >> So at the end we as a community can ask ourselves what is the reward
> >> model for such shitty work?
> >> And also what are we ready to give so that Pharo maintainers do such 
> >> boring job.
> >>
> >> Right now without really doing it consciously I see myself doing
> >> either stupid fix or working on side projects
> >> and this is not a good long term approach because the core of Pharo
> >> needs a lot of work.
> >>
> >> Stef
> >> On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe  wrote:
> >>>
> >>>
> >>>
>  On 2 Nov 2018, at 12:01, Norbert Hartl  wrote:
> 
>  Hi
> 
> > Am 02.11.2018 um 11:15 schrieb Stephane Ducasse 
> > :
> >
> > Hi
> >
> > Pay attention the following email is not nice and politically correct
> > but it is important for the speed of improvements in Pharo.
> >
>  thanks for the disclaimer. It is important. I copy that because mine 
>  might be not political correct, too.
> 
> > I think that we are doing our best when dealing with subproject code.
> > Now if we are forced to publish each little changes
> > on each subproject and wait that something gets integrated into each
> > subproject, then I would prefer to stop Pharo and do something else.
> > We cannot ask someone to stop in the middle of a massive super boring
> > and feel like shit cleaning in addition to stop and
> > please publish a PR and wait that it gets integrated and wait that
> > Pharo integrates the new version.
> > Let us be a bit serious and pro here.
> >
>  I know this. And I’m taking it serious because I want to talk about it. 
>  If you decide that you rather be offended then talk please do. I find it 
>  annoying that a lot of topics are washed away because someone is 
>  offended. That is just another way of killing communication although it 
>  is a state-of-the-art these days.
> 
> > Or we should drop subprojects. Because changing Pharo is getting a
> > painful. Imagine just a change cross cutting several subprojects.
> > For example, I did not fix the use of deprecated classes in Iceberg
> > because I got distracted by the where is the project hosted and I was
> > not connected on a good web connection. I changed calypso and
> > published to calypso but if the feedback loop is too long it means
> > that
> > we will prefer to work on our own projects (because we have also our
> > own projects and there velocity is high and 

[Pharo-dev] [Pharo 7.0-dev] Build #1369: 22636 - Integrate Iceberg 1.4.0

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #1369 was: SUCCESS.

The Pull Request #1956 was integrated: "22636  - Integrate Iceberg 1.4.0"
Pull request url: https://github.com/pharo-project/pharo/pull/1956

Issue Url: https://pharo.fogbugz.com/f/cases/22636
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1369/

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Esteban Lorenzano]

> On 6 Nov 2018, at 15:44, Esteban Maringolo  wrote:
> 
> Yes, but I cannot fix the whole input event handler just to assign a shortcut 
> ;)
> 
> 
> Ps: *Yes*, to fix the event handler is in the TODO list. But if I jump to fix 
> what is broken each time I found something I will be trap in an endless loop 
> until I retire or die.
> 
> The "problem" would be to assign a sub-optimal shortcut as a workaround for a 
> bug. 
> 
> Not because it cannot be changed later, but because we all know nothing is as 
> permanent as temporary solutions :)
> 
> I like the Shift+Shift proposed, but I don't know if the current handler can 
> process it.

Nope :/

> 
> Esteban A. Maringolo
>  

[Pharo-dev] [Pharo 7.0-dev] Build #1368: 22239-DataAndTimeTesttestAsDateAndTime-is-meaningful-2

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #1368 was: FAILURE.

The Pull Request #1948 was integrated: 
"22239-DataAndTimeTesttestAsDateAndTime-is-meaningful-2"
Pull request url: https://github.com/pharo-project/pharo/pull/1948

Issue Url: https://pharo.fogbugz.com/f/cases/22239
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1368/

[Pharo-dev] [Pharo 7.0-dev] Build #1367: 22560-Clean-magic-numbers-in-InputEventHandler-subclasses

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #1367 was: FAILURE.

The Pull Request #1896 was integrated: 
"22560-Clean-magic-numbers-in-InputEventHandler-subclasses"
Pull request url: https://github.com/pharo-project/pharo/pull/1896

Issue Url: https://pharo.fogbugz.com/f/cases/22560
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1367/

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Esteban Maringolo]

>
> Yes, but I cannot fix the whole input event handler just to assign a
> shortcut ;)
>
>
> Ps: *Yes*, to fix the event handler is in the TODO list. But if I jump to
> fix what is broken each time I found something I will be trap in an endless
> loop until I retire or die.
>

The "problem" would be to assign a sub-optimal shortcut as a workaround for
a bug.

Not because it cannot be changed later, but because we all know nothing is
as permanent as temporary solutions :)

I like the Shift+Shift proposed, but I don't know if the current handler
can process it.

Esteban A. Maringolo

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Peter Uhnak]

> Yes, but I cannot fix the whole input event handler just to assign a
shortcut ;)

nono, there are two styles of shortcut definition, one is broken and the
other is not...
but maybe once I fix the mentioned PR this will work automatically... I
will test it later this week.

P

On Tue, Nov 6, 2018 at 3:39 PM Esteban Lorenzano 
wrote:

>
>
> On 6 Nov 2018, at 15:16, Peter Uhnak  wrote:
>
>
>
> On Tue, Nov 6, 2018 at 1:11 PM Esteban Lorenzano 
> wrote:
>
>>
>>
>> On 6 Nov 2018, at 12:58, Esteban Maringolo  wrote:
>>
>> If Shift+Enter opens Spotter, why not use Cmd+Shift+Enter for the
>> contextual one?
>>
>>
>> Because it does not works (already tried) :)
>>
>
> iirc the problem is that the old-style shortcut definition corrupts the
> shortcut…
>
>
> Yes, but I cannot fix the whole input event handler just to assign a
> shortcut ;)
>
> Esteban
>
> Ps: *Yes*, to fix the event handler is in the TODO list. But if I jump to
> fix what is broken each time I found something I will be trap in an endless
> loop until I retire or die.
>
>
> which reminds me that I should get back to fixing this
> https://github.com/pharo-ide/Commander/pull/39
>
>
>

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Esteban Lorenzano]

> On 6 Nov 2018, at 15:16, Peter Uhnak  wrote:
> 
> 
> 
> On Tue, Nov 6, 2018 at 1:11 PM Esteban Lorenzano  > wrote:
> 
> 
>> On 6 Nov 2018, at 12:58, Esteban Maringolo > > wrote:
>> 
>> If Shift+Enter opens Spotter, why not use Cmd+Shift+Enter for the contextual 
>> one?
> 
> Because it does not works (already tried) :)
> 
> iirc the problem is that the old-style shortcut definition corrupts the 
> shortcut…

Yes, but I cannot fix the whole input event handler just to assign a shortcut ;)

Esteban

Ps: *Yes*, to fix the event handler is in the TODO list. But if I jump to fix 
what is broken each time I found something I will be trap in an endless loop 
until I retire or die.


> which reminds me that I should get back to fixing this 
> https://github.com/pharo-ide/Commander/pull/39 
>  

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1365: 22635-Welcome-help-should-show-build-hash-

[Ben Coman]

On Tue, 6 Nov 2018 at 20:57,  wrote:

> There is a new Pharo build available!
>
> The status of the build #1365 was: SUCCESS.
>
> The Pull Request #1955 was integrated:
> "22635-Welcome-help-should-show-build-hash-"
> Pull request url: https://github.com/pharo-project/pharo/pull/1955


I noticed the result of this when I downloaded the latest build
and thought it was a nice touch.

cheers -ben

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Peter Uhnak]

On Tue, Nov 6, 2018 at 1:11 PM Esteban Lorenzano 
wrote:

>
>
> On 6 Nov 2018, at 12:58, Esteban Maringolo  wrote:
>
> If Shift+Enter opens Spotter, why not use Cmd+Shift+Enter for the
> contextual one?
>
>
> Because it does not works (already tried) :)
>

iirc the problem is that the old-style shortcut definition corrupts the
shortcut... which reminds me that I should get back to fixing this
https://github.com/pharo-ide/Commander/pull/39

[Pharo-dev] [Pharo 7.0-dev] Build #1366: 22621-FileReferencemoveTo-doesnt-work-with-directories

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #1366 was: SUCCESS.

The Pull Request #1949 was integrated: 
"22621-FileReferencemoveTo-doesnt-work-with-directories"
Pull request url: https://github.com/pharo-project/pharo/pull/1949

Issue Url: https://pharo.fogbugz.com/f/cases/22621
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1366/

Re: [Pharo-dev] Zinc Websockets

[Esteban Maringolo]

To use Zinc WS you might need to port Zinc first, which would be great BTW.

But if I recall correctly VW already has WebSockets and HTTP 2.0 support in
their SiouX HTTP framework.

Regards,

Esteban A. Maringolo


El lun., 5 nov. 2018 a las 22:07, Shaping () escribió:

> Hi all.
>
> What is the easiest way to port Zinc Websockets to VW?  Has this been done?
>
>
> Shaping
>
>
>

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[p...@highoctane.be]

IntelliJ search everywhere is shift shift.

Kind of neat as well.

Phil

On Tue, Nov 6, 2018, 13:34 Ben Coman  Not really sure if this is a good idea, but why not share...
>
> How about Shift-Enter-Enter.  Kind of like a double click.
> Because "local" is kind of like going deeper, kind of like entering a
> house and then entering a room, kind of like entering twice.
>
> Yeah, I know a lot of "kind of like"s
> cheers -ben
>
> On Tue, 6 Nov 2018 at 20:11, Esteban Lorenzano 
> wrote:
>
>>
>>
>> On 6 Nov 2018, at 12:58, Esteban Maringolo  wrote:
>>
>> If Shift+Enter opens Spotter, why not use Cmd+Shift+Enter for the
>> contextual one?
>>
>>
>> Because it does not works (already tried) :)
>>
>> Esteban
>>
>>
>> So the canonical shortcut is Shift+Enter and there is a modifier to open
>> it contextualized, could be Cmd/Ctrl or Meta/Win.
>>
>> Regards,
>>
>> Esteban A. Maringolo
>>
>>
>> El mar., 6 nov. 2018 a las 7:56, Esteban Lorenzano ()
>> escribió:
>>
>>> Hello,
>>>
>>> Most of you don’t know it, but Calypso incorporates an option to show a
>>> “contextual spotter” which will list all available commands in the context
>>> you selected.
>>> This is meant to help on discoverability and reachability of commands
>>> available.
>>>
>>> This is *in addition to shortcuts* not a replace of them (but lets be
>>> honest, we have far more commands than those that are possible to handle
>>> with a simple shortcut).
>>>
>>> Anyway, originally I mapped this command to meta+/, which fitted well
>>> with my keyboard and language, but seems is not the case for many others
>>> (and this is not working at all on windows).
>>>
>>> So. I’m looking for options :)
>>>
>>> So far I have this two ideas:
>>>
>>> 1- alt+enter
>>> 2- meta+h
>>>
>>> First one looks nice, but I’m not sure it will work on all
>>> platforms/combinations. What do you think?
>>>
>>> Esteban
>>>
>>> Ps: I will also add an icon somewhere to expose the contextual spotter.
>>>
>>>
>>>
>>

[Pharo-dev] [Pharo 7.0-dev] Build #1365: 22635-Welcome-help-should-show-build-hash-

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #1365 was: SUCCESS.

The Pull Request #1955 was integrated: 
"22635-Welcome-help-should-show-build-hash-"
Pull request url: https://github.com/pharo-project/pharo/pull/1955

Issue Url: https://pharo.fogbugz.com/f/cases/22635
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1365/

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Ben Coman]

Not really sure if this is a good idea, but why not share...

How about Shift-Enter-Enter.  Kind of like a double click.
Because "local" is kind of like going deeper, kind of like entering a house
and then entering a room, kind of like entering twice.

Yeah, I know a lot of "kind of like"s
cheers -ben

On Tue, 6 Nov 2018 at 20:11, Esteban Lorenzano  wrote:

>
>
> On 6 Nov 2018, at 12:58, Esteban Maringolo  wrote:
>
> If Shift+Enter opens Spotter, why not use Cmd+Shift+Enter for the
> contextual one?
>
>
> Because it does not works (already tried) :)
>
> Esteban
>
>
> So the canonical shortcut is Shift+Enter and there is a modifier to open
> it contextualized, could be Cmd/Ctrl or Meta/Win.
>
> Regards,
>
> Esteban A. Maringolo
>
>
> El mar., 6 nov. 2018 a las 7:56, Esteban Lorenzano ()
> escribió:
>
>> Hello,
>>
>> Most of you don’t know it, but Calypso incorporates an option to show a
>> “contextual spotter” which will list all available commands in the context
>> you selected.
>> This is meant to help on discoverability and reachability of commands
>> available.
>>
>> This is *in addition to shortcuts* not a replace of them (but lets be
>> honest, we have far more commands than those that are possible to handle
>> with a simple shortcut).
>>
>> Anyway, originally I mapped this command to meta+/, which fitted well
>> with my keyboard and language, but seems is not the case for many others
>> (and this is not working at all on windows).
>>
>> So. I’m looking for options :)
>>
>> So far I have this two ideas:
>>
>> 1- alt+enter
>> 2- meta+h
>>
>> First one looks nice, but I’m not sure it will work on all
>> platforms/combinations. What do you think?
>>
>> Esteban
>>
>> Ps: I will also add an icon somewhere to expose the contextual spotter.
>>
>>
>>
>

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Esteban Lorenzano]

> On 6 Nov 2018, at 12:58, Esteban Maringolo  wrote:
> 
> If Shift+Enter opens Spotter, why not use Cmd+Shift+Enter for the contextual 
> one?

Because it does not works (already tried) :)

Esteban

> 
> So the canonical shortcut is Shift+Enter and there is a modifier to open it 
> contextualized, could be Cmd/Ctrl or Meta/Win.
> 
> Regards,
> 
> Esteban A. Maringolo
> 
> 
> El mar., 6 nov. 2018 a las 7:56, Esteban Lorenzano ( >) escribió:
> Hello, 
> 
> Most of you don’t know it, but Calypso incorporates an option to show a 
> “contextual spotter” which will list all available commands in the context 
> you selected.
> This is meant to help on discoverability and reachability of commands 
> available.
> 
> This is *in addition to shortcuts* not a replace of them (but lets be honest, 
> we have far more commands than those that are possible to handle with a 
> simple shortcut).
> 
> Anyway, originally I mapped this command to meta+/, which fitted well with my 
> keyboard and language, but seems is not the case for many others (and this is 
> not working at all on windows).
> 
> So. I’m looking for options :)
> 
> So far I have this two ideas: 
> 
> 1- alt+enter
> 2- meta+h
> 
> First one looks nice, but I’m not sure it will work on all 
> platforms/combinations. What do you think?
> 
> Esteban
> 
> Ps: I will also add an icon somewhere to expose the contextual spotter.
> 
> 

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Esteban Maringolo]

If Shift+Enter opens Spotter, why not use Cmd+Shift+Enter for the
contextual one?

So the canonical shortcut is Shift+Enter and there is a modifier to open it
contextualized, could be Cmd/Ctrl or Meta/Win.

Regards,

Esteban A. Maringolo


El mar., 6 nov. 2018 a las 7:56, Esteban Lorenzano ()
escribió:

> Hello,
>
> Most of you don’t know it, but Calypso incorporates an option to show a
> “contextual spotter” which will list all available commands in the context
> you selected.
> This is meant to help on discoverability and reachability of commands
> available.
>
> This is *in addition to shortcuts* not a replace of them (but lets be
> honest, we have far more commands than those that are possible to handle
> with a simple shortcut).
>
> Anyway, originally I mapped this command to meta+/, which fitted well with
> my keyboard and language, but seems is not the case for many others (and
> this is not working at all on windows).
>
> So. I’m looking for options :)
>
> So far I have this two ideas:
>
> 1- alt+enter
> 2- meta+h
>
> First one looks nice, but I’m not sure it will work on all
> platforms/combinations. What do you think?
>
> Esteban
>
> Ps: I will also add an icon somewhere to expose the contextual spotter.
>
>
>

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Esteban Lorenzano]

> On 6 Nov 2018, at 12:02, Guillermo Polito  wrote:
> 
> Q: does "contextual spotter" inherit all the features from the global one?

no 

> 
> If yes, why not overriding shift+enter?
>  - if you're on a global scope, you open a global spotter
>  - if you're on a local scope, you open a local spotter (that also does 
> global spotter things)

It does not applies.
Contextual explorer shows available commands. 
- Merge them wit the “global spotter” would be too much information hence 
confusing and complicated to find.
- hiding the global spotter when contextual is show would have negative impact 
since users still want to use spotter.

> 
> Also, it will be more easy to discover => just a single shortcut, and people 
> will start using it directly, maybe even without knowing it

Yes, discovery advantages are true.
Yet, difficulties to organise that information stays. 
(But we can see how it looks)

Esteban

> 
> On Tue, Nov 6, 2018 at 11:56 AM Esteban Lorenzano  > wrote:
> Hello, 
> 
> Most of you don’t know it, but Calypso incorporates an option to show a 
> “contextual spotter” which will list all available commands in the context 
> you selected.
> This is meant to help on discoverability and reachability of commands 
> available.
> 
> This is *in addition to shortcuts* not a replace of them (but lets be honest, 
> we have far more commands than those that are possible to handle with a 
> simple shortcut).
> 
> Anyway, originally I mapped this command to meta+/, which fitted well with my 
> keyboard and language, but seems is not the case for many others (and this is 
> not working at all on windows).
> 
> So. I’m looking for options :)
> 
> So far I have this two ideas: 
> 
> 1- alt+enter
> 2- meta+h
> 
> First one looks nice, but I’m not sure it will work on all 
> platforms/combinations. What do you think?
> 
> Esteban
> 
> Ps: I will also add an icon somewhere to expose the contextual spotter.
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[p...@highoctane.be]

Alt enter hass my vote provided it works on Windows as well.

Phil

On Tue, Nov 6, 2018, 11:56 Esteban Lorenzano  Hello,
>
> Most of you don’t know it, but Calypso incorporates an option to show a
> “contextual spotter” which will list all available commands in the context
> you selected.
> This is meant to help on discoverability and reachability of commands
> available.
>
> This is *in addition to shortcuts* not a replace of them (but lets be
> honest, we have far more commands than those that are possible to handle
> with a simple shortcut).
>
> Anyway, originally I mapped this command to meta+/, which fitted well with
> my keyboard and language, but seems is not the case for many others (and
> this is not working at all on windows).
>
> So. I’m looking for options :)
>
> So far I have this two ideas:
>
> 1- alt+enter
> 2- meta+h
>
> First one looks nice, but I’m not sure it will work on all
> platforms/combinations. What do you think?
>
> Esteban
>
> Ps: I will also add an icon somewhere to expose the contextual spotter.
>
>
>

[Pharo-dev] [Pharo 7.0-dev] Build #1364: 22634-SystemVersionTesttestDoNotBreakSmalltalkVersion

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #1364 was: FAILURE.

The Pull Request #1954 was integrated: 
"22634-SystemVersionTesttestDoNotBreakSmalltalkVersion"
Pull request url: https://github.com/pharo-project/pharo/pull/1954

Issue Url: https://pharo.fogbugz.com/f/cases/22634
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1364/

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Sven Van Caekenberghe]

maybe global/local scope could also be a switch, once you are in spotter

> On 6 Nov 2018, at 12:02, Guillermo Polito  wrote:
> 
> Q: does "contextual spotter" inherit all the features from the global one?
> 
> If yes, why not overriding shift+enter?
>  - if you're on a global scope, you open a global spotter
>  - if you're on a local scope, you open a local spotter (that also does 
> global spotter things)
> 
> Also, it will be more easy to discover => just a single shortcut, and people 
> will start using it directly, maybe even without knowing it
> 
> On Tue, Nov 6, 2018 at 11:56 AM Esteban Lorenzano  wrote:
> Hello, 
> 
> Most of you don’t know it, but Calypso incorporates an option to show a 
> “contextual spotter” which will list all available commands in the context 
> you selected.
> This is meant to help on discoverability and reachability of commands 
> available.
> 
> This is *in addition to shortcuts* not a replace of them (but lets be honest, 
> we have far more commands than those that are possible to handle with a 
> simple shortcut).
> 
> Anyway, originally I mapped this command to meta+/, which fitted well with my 
> keyboard and language, but seems is not the case for many others (and this is 
> not working at all on windows).
> 
> So. I’m looking for options :)
> 
> So far I have this two ideas: 
> 
> 1- alt+enter
> 2- meta+h
> 
> First one looks nice, but I’m not sure it will work on all 
> platforms/combinations. What do you think?
> 
> Esteban
> 
> Ps: I will also add an icon somewhere to expose the contextual spotter.
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13

Re: [Pharo-dev] [ANN] The STON Specification

[Eliot Miranda]

Hi Shaping,

Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to
VW's Double. In 64-bit SmallFloat64 maps exactly to SmallDouble.  But I
wonder whether there is any issue here.  STON would use the print strings
for (PSC) Float / (VW) Double, and so deseerialization on Pharo would
automatically produce the right class.  Going in the other direction might
need some help.  APF needs support in PSC before one can port, but are
representable as suitably-sized word arrays. There is no support for __float128
anywhere in the VM (e.g. not even in the FFI) on PSC as yet.

On Tue, Nov 6, 2018 at 12:56 AM Shaping  wrote:

> STON is able to serialise Pharo’s Floats, what do you mean by double ?
>
>
>
> Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits,
> with a range between =10^307 and 10^307.
>
>
>
> Additionally, I recently asked Sven if t would be possible to store
> ScaledDecimals (I think it implements what you call
> ArbitraryPrecisionFloats) without loss of precision.
>
>
>
> I’m referring VW’s Double (and SmallDouble in 64-bit engines/images).
> APFs are binary representations that can be arbitrarily large, using
> Integers (LargePositiveIntegers for example) to model the bits of the
> mantissa.
>
>
>
> Before, because STON extends JSON, it was storing all kind of numbers
> either as float or integer.
>
>
>
> Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of
> precision through serialisation as float, what was done before).
>
>
>
> But I do not know if this change is integrated in recent images yet.
>
>
>
> …..
>
>
>
> Number subclass: #Float
>
> instanceVariableNames: ''
>
> classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2
> MaxVal MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi
> RadiansPerDegree Sqrt2 ThreePi Twopi'
>
> poolDictionaries: ''
>
> category: 'Kernel-Numbers'
>
>
>
>
>
> My instances represent IEEE-754 floating-point double-precision numbers.
> They have about 16 digits of accuracy and their range is between plus and
> minus 10^307. Some valid examples are:
>
>
>
> 8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12
>
> ….
>
>
>
> I see that Pharo’s Float is VW’s Double.   So then I just need to be able
> to serialize APF.
>
>
>
> ….
>
> FIFloatType subclass: #FFIFloat128
>
> instanceVariableNames: ''
>
> classVariableNames: ''
>
> poolDictionaries: ''
>
> category: 'UnifiedFFI-Types'
>
>
>
>
>
> I'm a 128bits (cuadruple precision) float.
>
> It is usually not used, but some compiler modes support it (__float128 in
> gcc)
>
>
>
> THIS IS NOT YET SUPPORTED
>
> ….
>
>
>
> The class above is also from the Pharo 7 image.  This is the largest of
> the c-type FFIFloats.  Any Float classes of this size and larger for the
> Smalltalk heap on 64-bit Pharo?
>
>
>
>
>
> Cheers,
>
>
>
> Shaping
>
>
>
>
>
> Le 6 nov. 2018 à 06:58, Shaping  a écrit :
>
>
>
> (Having domain problems recently.  Please excuse this posting if you have
> seen it twice.  I've not seen it appear yet on the list.)
>
>
> Can STON be extended to handle Doubles and ArbitraryPrecisionFloats?
>
> Shaping
>
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org
> ] On Behalf Of
> David T. Lewis
> Sent: Wednesday, October 31, 2018 14:58
> To: Pharo Development List 
> Subject: Re: [Pharo-dev] [ANN] The STON Specification
>
> This is very clear and well written.
>
> Dave
>
>
> Hi,
>
> Since there can never be enough documentation I finally took some time
> to write a more formal description of STON as a data format.
>
>  https://github.com/svenvc/ston/blob/master/ston-spec.md
>
> The idea is to let this stabilise a bit and to then update the two
> other documents describing STON, where necessary:
>
>  https://github.com/svenvc/ston/blob/master/ston-paper.md
>
> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc
> cessfulBuild/artifact/book-result/STON/STON.html
>
> Also, the latest changes in STON have to make their way to the Pharo
> image as well.
>
>  https://github.com/svenvc/ston
>
> All feedback is welcome.
>
> Sven
>
>
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
>
>
>
>
>
>
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Guillermo Polito]

Q: does "contextual spotter" inherit all the features from the global one?

If yes, why not overriding shift+enter?
 - if you're on a global scope, you open a global spotter
 - if you're on a local scope, you open a local spotter (that also does
global spotter things)

Also, it will be more easy to discover => just a single shortcut, and
people will start using it directly, maybe even without knowing it

On Tue, Nov 6, 2018 at 11:56 AM Esteban Lorenzano 
wrote:

> Hello,
>
> Most of you don’t know it, but Calypso incorporates an option to show a
> “contextual spotter” which will list all available commands in the context
> you selected.
> This is meant to help on discoverability and reachability of commands
> available.
>
> This is *in addition to shortcuts* not a replace of them (but lets be
> honest, we have far more commands than those that are possible to handle
> with a simple shortcut).
>
> Anyway, originally I mapped this command to meta+/, which fitted well with
> my keyboard and language, but seems is not the case for many others (and
> this is not working at all on windows).
>
> So. I’m looking for options :)
>
> So far I have this two ideas:
>
> 1- alt+enter
> 2- meta+h
>
> First one looks nice, but I’m not sure it will work on all
> platforms/combinations. What do you think?
>
> Esteban
>
> Ps: I will also add an icon somewhere to expose the contextual spotter.
>
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

[Pharo-dev] Looking for a good shortcut for "contextual spotter"

[Esteban Lorenzano]

Hello, 

Most of you don’t know it, but Calypso incorporates an option to show a 
“contextual spotter” which will list all available commands in the context you 
selected.
This is meant to help on discoverability and reachability of commands available.

This is *in addition to shortcuts* not a replace of them (but lets be honest, 
we have far more commands than those that are possible to handle with a simple 
shortcut).

Anyway, originally I mapped this command to meta+/, which fitted well with my 
keyboard and language, but seems is not the case for many others (and this is 
not working at all on windows).

So. I’m looking for options :)

So far I have this two ideas: 

1- alt+enter
2- meta+h

First one looks nice, but I’m not sure it will work on all 
platforms/combinations. What do you think?

Esteban

Ps: I will also add an icon somewhere to expose the contextual spotter.

Re: [Pharo-dev] Unable to repair repository

[Alistair Grant]

Hi Guille,

On Tue, 6 Nov 2018 at 10:43, Guillermo Polito  wrote:
>
> Hi Alistair,
>
> On Tue, Nov 6, 2018 at 9:39 AM Alistair Grant  wrote:
>>
>> Hi Everyone,
>>
>> In the latest Pharo (88c6b8d), attempting to repair the pharo
>> repository, i.e. clone it, first a warning is raised:
>>
>> "There is no associated repository configured."
>>
>> and then a DNU: #pathString was sent to nil.
>>
>> The DNU is because IceTipCopyCommitishCommand>>canBeExecutedInContext:
>> now sends #commitId instead of #shortCommitId.
>> IceTipRepositoryModel>>shortCommitId has an exception handler, while
>> #commitId doesn't.
>>
>> Can someone explain why the warning was added?  It is a bit annoying
>> to have to click through dialogs telling me that the repository I'm
>> trying to create needs to be created.
>
>
> I've seen that yesterday evening, and I've fixed it here 
> https://github.com/pharo-vcs/iceberg/issues/1068.
> I've put links on the original issues that caused the regression, and the 
> workaround meanwhile we prepare a new version.
>
> A fix will be pushed in a 1.3.2 version in the following hours ^^.

Cool, thanks!  (I had already added the exception handler to #commitId
as a partial workaround).


>> Using the generic Error exception handler has the risk of hiding other
>> problems.  Wouldn't it be better to create a IceRepositoryMissing
>> error, or similar?
>
>
> The support for missing repositories should be indeed revisited a bit and 
> enhanced.
> Particularly, we have other issues related to this that we have not worked on 
> yet like this one:
>
> https://github.com/pharo-vcs/iceberg/issues/949
>
> This issue is pretty important, but no time to work on it yet, so if someone 
> wants to propose a solution, we take it :)...

I'm trying to review Pavel's PR #1953 [1], but may take a look afterwards.

Thanks again,
Alistair

[1] https://github.com/pharo-project/pharo/pull/1953

Re: [Pharo-dev] Zinc Websockets

[Sven Van Caekenberghe]

Hi,

> On 6 Nov 2018, at 02:06, Shaping  wrote:
> 
> Hi all.
> 
> What is the easiest way to port Zinc Websockets to VW?  Has this been done?
> 
> 
> Shaping

Zinc-WebSockets-Core is actually not that big, but it builds on top of the Zinc 
HTTP Components framework and is kind of integrated with it.

I would suggest you start by studying its implementation and then evaluate how 
to get this working on top of VW's HTTP classes.

Sven

Re: [Pharo-dev] Unable to repair repository

[Guillermo Polito]

Hi Alistair,

On Tue, Nov 6, 2018 at 9:39 AM Alistair Grant  wrote:

> Hi Everyone,
>
> In the latest Pharo (88c6b8d), attempting to repair the pharo
> repository, i.e. clone it, first a warning is raised:
>
> "There is no associated repository configured."
>
> and then a DNU: #pathString was sent to nil.
>
> The DNU is because IceTipCopyCommitishCommand>>canBeExecutedInContext:
> now sends #commitId instead of #shortCommitId.
> IceTipRepositoryModel>>shortCommitId has an exception handler, while
> #commitId doesn't.
>
> Can someone explain why the warning was added?  It is a bit annoying
> to have to click through dialogs telling me that the repository I'm
> trying to create needs to be created.
>

I've seen that yesterday evening, and I've fixed it here
https://github.com/pharo-vcs/iceberg/issues/1068.
I've put links on the original issues that caused the regression, and the
workaround meanwhile we prepare a new version.

A fix will be pushed in a 1.3.2 version in the following hours ^^.


>
> Using the generic Error exception handler has the risk of hiding other
> problems.  Wouldn't it be better to create a IceRepositoryMissing
> error, or similar?
>

The support for missing repositories should be indeed revisited a bit and
enhanced.
Particularly, we have other issues related to this that we have not worked
on yet like this one:

https://github.com/pharo-vcs/iceberg/issues/949

This issue is pretty important, but no time to work on it yet, so if
someone wants to propose a solution, we take it :)...

Re: [Pharo-dev] [ANN] The STON Specification

[Shaping]

STON is able to serialise Pharo’s Floats, what do you mean by double ?

 

Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, with 
a range between =10^307 and 10^307.

 

Additionally, I recently asked Sven if t would be possible to store 
ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) 
without loss of precision.

 

I’m referring VW’s Double (and SmallDouble in 64-bit engines/images).  APFs are 
binary representations that can be arbitrarily large, using Integers 
(LargePositiveIntegers for example) to model the bits of the mantissa.

 

Before, because STON extends JSON, it was storing all kind of numbers either as 
float or integer.

 

Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of 
precision through serialisation as float, what was done before).

 

But I do not know if this change is integrated in recent images yet.

 

…..

 

Number subclass: #Float

instanceVariableNames: ''

classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 MaxVal 
MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi RadiansPerDegree 
Sqrt2 ThreePi Twopi'

poolDictionaries: ''

category: 'Kernel-Numbers'

 

 

My instances represent IEEE-754 floating-point double-precision numbers.  They 
have about 16 digits of accuracy and their range is between plus and minus 
10^307. Some valid examples are:



8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12

….

 

I see that Pharo’s Float is VW’s Double.   So then I just need to be able to 
serialize APF.

 

….

FIFloatType subclass: #FFIFloat128

instanceVariableNames: ''

classVariableNames: ''

poolDictionaries: ''

category: 'UnifiedFFI-Types'

 

 

I'm a 128bits (cuadruple precision) float. 

It is usually not used, but some compiler modes support it (__float128 in gcc)

 

THIS IS NOT YET SUPPORTED

….

 

The class above is also from the Pharo 7 image.  This is the largest of the 
c-type FFIFloats.  Any Float classes of this size and larger for the Smalltalk 
heap on 64-bit Pharo?  

 

 

Cheers,

 

Shaping

 

 

Le 6 nov. 2018 à 06:58, Shaping mailto:shap...@uurda.org> > 
a écrit :

 

(Having domain problems recently.  Please excuse this posting if you have
seen it twice.  I've not seen it appear yet on the list.)


Can STON be extended to handle Doubles and ArbitraryPrecisionFloats?

Shaping

-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
David T. Lewis
Sent: Wednesday, October 31, 2018 14:58
To: Pharo Development List mailto:pharo-dev@lists.pharo.org> >
Subject: Re: [Pharo-dev] [ANN] The STON Specification

This is very clear and well written.

Dave




Hi,

Since there can never be enough documentation I finally took some time 
to write a more formal description of STON as a data format.

 https://github.com/svenvc/ston/blob/master/ston-spec.md

The idea is to let this stabilise a bit and to then update the two 
other documents describing STON, where necessary:

 https://github.com/svenvc/ston/blob/master/ston-paper.md

https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc
cessfulBuild/artifact/book-result/STON/STON.html

Also, the latest changes in STON have to make their way to the Pharo 
image as well.

 https://github.com/svenvc/ston

All feedback is welcome.

Sven


--
Sven Van Caekenberghe
Proudly supporting Pharo
http://pharo.org
http://association.pharo.org
http://consortium.pharo.org












 

[Pharo-dev] Unable to repair repository

[Alistair Grant]

Hi Everyone,

In the latest Pharo (88c6b8d), attempting to repair the pharo
repository, i.e. clone it, first a warning is raised:

"There is no associated repository configured."

and then a DNU: #pathString was sent to nil.

The DNU is because IceTipCopyCommitishCommand>>canBeExecutedInContext:
now sends #commitId instead of #shortCommitId.
IceTipRepositoryModel>>shortCommitId has an exception handler, while
#commitId doesn't.

Can someone explain why the warning was added?  It is a bit annoying
to have to click through dialogs telling me that the repository I'm
trying to create needs to be created.

Using the generic Error exception handler has the risk of hiding other
problems.  Wouldn't it be better to create a IceRepositoryMissing
error, or similar?

Thanks,
Alistair

Re: [Pharo-dev] [ANN] Iceberg v1.3.1

[Cyril Ferlicot]

On Mon, Nov 5, 2018 at 5:09 PM Hernán Morales Durand
 wrote:
>
> Hi Cyril,
>
> Does the update apply to Pharo 6.1?
>

Hi,

The version will not be present by default in Pharo 6.1 because it
cause too much changes to be in a minor release. (The last Iceberg
release in Pharo 6.1 was the 0.6 or 0.7 I think).

But it can be loaded via the script in the README.



> Cheers,
>
> Hernán
>


--
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-dev] [ANN] The STON Specification

[Julien]

Hello,

STON is able to serialise Pharo’s Floats, what do you mean by double ?

Additionally, I recently asked Sven if t would be possible to store 
ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) 
without loss of precision.

Before, because STON extends JSON, it was storing all kind of numbers either as 
float or integer.

Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of 
precision through serialisation as float, what was done before).

But I do not know if this change is integrated in recent images yet.

Cheers,

Julien

---
Julien Delplanque
Doctorant à l’Université de Lille
http://juliendelplanque.be/phd.html
Equipe Rmod, Inria
Bâtiment B 40, Avenue Halley 59650 Villeneuve d'Ascq
Numéro de téléphone: +333 59 35 86 40

> Le 6 nov. 2018 à 06:58, Shaping  a écrit :
> 
> (Having domain problems recently.  Please excuse this posting if you have
> seen it twice.  I've not seen it appear yet on the list.)
> 
> 
> Can STON be extended to handle Doubles and ArbitraryPrecisionFloats?
> 
> Shaping
> 
> -Original Message-
> From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of
> David T. Lewis
> Sent: Wednesday, October 31, 2018 14:58
> To: Pharo Development List 
> Subject: Re: [Pharo-dev] [ANN] The STON Specification
> 
> This is very clear and well written.
> 
> Dave
> 
>> Hi,
>> 
>> Since there can never be enough documentation I finally took some time 
>> to write a more formal description of STON as a data format.
>> 
>>  https://github.com/svenvc/ston/blob/master/ston-spec.md
>> 
>> The idea is to let this stabilise a bit and to then update the two 
>> other documents describing STON, where necessary:
>> 
>>  https://github.com/svenvc/ston/blob/master/ston-paper.md
>> 
>> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc
>> cessfulBuild/artifact/book-result/STON/STON.html
>> 
>> Also, the latest changes in STON have to make their way to the Pharo 
>> image as well.
>> 
>>  https://github.com/svenvc/ston
>> 
>> All feedback is welcome.
>> 
>> Sven
>> 
>> 
>> --
>> Sven Van Caekenberghe
>> Proudly supporting Pharo
>> http://pharo.org
>> http://association.pharo.org
>> http://consortium.pharo.org
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> 
>