date:20170224

Cool news.  I'll try it out soon.

I found this paper on Lowcode to share with other curious people...
  http://www.esug.org/data/ESUG2016/IWST/Papers/IWST_2016_paper_16.pdf

A few questions from that...


> our extended instructions do not perform run time type checking on their 
> inputs, so they do not have the overhead associated to dynamic message 
> lookup."

What happens if the wrong type object is passed to a lowcode method?


> Unfortunately, when we did this work the 64 bits version of Spur was 
> incomplete and in an experimental state [and we were] not able to compare the 
> performance difference for floating point arithmetics against a Smalltalk 
> with support for immediate floating point objects

Have you been able to do this performance comparison since the paper
was written?


cheers -ben

On Fri, Feb 24, 2017 at 9:02 AM, Ronie Salgado  wrote:
> Hello,
>
> Finally I am glad to announce a first release of Woden 2. I made a hopefully
> simplified process for loading Woden 2 out of the box.
>
> For loading and testing Woden 2, follow the instructions at:
>
> https://github.com/ronsaldo/woden2
>
> In this release, I am not loading the level editor by default because it
> depends on an outdated version of Bloc. Until I fix the dependency problem
> of the Level editor, it will remain unusable.
>
> Because Woden 2 requires Metal on OS X, it requires 64 bits on OS X, which
> can be unstable. This is tested on OS X El Capitan. I do not know whether it
> will work or not on OS X Sierra.
>
> Best regards,
> Ronie

Re: [Pharo-dev] [ANN] Woden 2 first release for OS X and Linux

2017-02-24 Thread Ronie Salgado

Hello,

I fixed several bugs with Vulkan, so now it is not crashing anymore when
using the Linux NVIDIA Vulkan driver. I still have to fix the stuttering
problem with Vulkam.

Best regards,
Ronie

2017-02-24 6:38 GMT-03:00 nolwenn :

> Wonderful ! I will try it soon.
>
> Thanks !
>
> Nolwenn
>
>
>
> --
> View this message in context: http://forum.world.st/ANN-
> Woden-2-first-release-for-OS-X-and-Linux-tp4935693p4935742.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

2017-02-24 Thread Sean P. DeNigris

Andreas Wacknitz wrote
> Everything that is used outside Pharo could have a fancy name.
> For internal tools and frameworks this is... like talking in argot and
> creates high walls around Pharo.

+100



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Any-idea-for-a-cool-name-for-the-remote-tool-suite-tp4932008p4935862.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Code Completion in Pharo

Another random idea, that you can use something similar to Finder>Examples
from within the debugger.  That is, a shortcut brings up a small popup
dialog kind-of inline with the cursor where you can feed live variables
into the pattern matching.

cheers -ben

On Sat, Feb 25, 2017 at 7:09 AM, Ben Coman  wrote:

> How would people feel about...
> when an item is selected from the code completion popup (e.g. with
> ) that the arguments get expanded as well.  These might show up red
> initially if there is no matching variable and easily show what needs to be
> edited.
>
> cheers -ben
>
> On Wed, Feb 15, 2017 at 1:57 AM,  wrote:
>
>> Hello to all,
>>
>> I am a student at the Faculty of Information Technology of the Czech
>> Technical University in Prague and I decided to make Code Completion in
>> Pharo the topic of my Bachelor's degree and try to improve it.
>>
>> If you have suggestions on what should change / how to change it so you
>> would be satisfied with it, I will appreciate any input on this topic. It
>> would mean a lot to me if you could find two minutes and take this survey
>> (there are only like 7 questions, so it won't take longer than those 2
>> minutes):
>>
>> https://docs.google.com/forms/d/e/1FAIpQLSd7lx6gIN079-vMvMwR
>> snA_AX_e_7sZEz2XJQ4059nk_-LV6w/viewform
>>
>> Regards
>>
>>
>> Lukas
>>
>
>

Re: [Pharo-dev] Code Completion in Pharo

How would people feel about...
when an item is selected from the code completion popup (e.g. with )
that the arguments get expanded as well.  These might show up red initially
if there is no matching variable and easily show what needs to be edited.

cheers -ben

On Wed, Feb 15, 2017 at 1:57 AM,  wrote:

> Hello to all,
>
> I am a student at the Faculty of Information Technology of the Czech
> Technical University in Prague and I decided to make Code Completion in
> Pharo the topic of my Bachelor's degree and try to improve it.
>
> If you have suggestions on what should change / how to change it so you
> would be satisfied with it, I will appreciate any input on this topic. It
> would mean a lot to me if you could find two minutes and take this survey
> (there are only like 7 questions, so it won't take longer than those 2
> minutes):
>
> https://docs.google.com/forms/d/e/1FAIpQLSd7lx6gIN079-vMvMwRsnA_AX_e_
> 7sZEz2XJQ4059nk_-LV6w/viewform
>
> Regards
>
>
> Lukas
>

Re: [Pharo-dev] Raw pane on byteStrings


Hi Andrei,

Le 24/02/2017 à 17:02, Andrei Chis a écrit :

Hi Thierry,

Strangely enough I'm getting different times on my machine
Just to start from the same baseline in a fresh Pharo 60411 image with
no changes to any of the inspectors over a series of runs I get:

array := (1 to: 100) asArray.
[array inspect] timeToRun.   "0:00:00:00.145"
[GTInspector inspect: array] timeToRun. "0:00:00:00.031"


Yes, this is expected. I'm not comparing to the standard EyeInspector, 
but with my experiments with a FastTable-derived widget and the 
EyeInspector model. GTInspector is a lot faster than the normal 
EyeInspector.


As default (the only one displaying 100k elements is the AltInspector)

| array |
array := (1 to: 100) asArray.
[AltInspector inspect: array ] timeToRun. "0:00:00:00.096"
[EyeInspector inspect: array] timeToRun.  "0:00:00:00.364"
[GTInspector inspect: array] timeToRun. "0:00:00:00.065"


If I change indexableDisplayLimit to 5 and remove the Items view
then I get:

[GTInspector inspect: array] timeToRun.  "0:00:00:00.124"


[GTInspector inspect: array] timeToRun. "0:00:00:00.256"

So this time is to be compared to the "0:00:00:00.096".


I'm really interested in seeing what makes GTInspector slower on your
machine. Did you do other optimizations to SpecInspector?


The optimisations are:
- remove Spec (revert to a pure morphic application),
- use a FastTable-derived widget for a tree view (with a 100k element 
limit),

- have the GT views as subitems in the widget.


I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7


Back on a Acer Chromebook C720p 1.4GHz Intel Celeron, with vmLatest.

5.0-201702231204  Thu Feb 23 12:36:20 UTC 2017 gcc 4.6.3 [Production 
Spur ITHB VM]
CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 
40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017
StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 
40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 23 2017
VM: 201702231204 https://github.com/pharo-project/pharo-vm.git $ Date: 
Thu Feb 23 13:04:59 2017 +0100 $

Plugins: 201702231204 https://github.com/pharo-project/pharo-vm.git $
Linux testing-docker-b6b0368d-4817-4638-86be-f022b8a58580 
4.8.12-040812-generic #201612020431 SMP Fri Dec 2 09:33:31 UTC 2016 i686 
i686 i386 GNU/Linux




Pharo VM version:
CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid:
16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880
uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
g...@github.com:pharo-project/pharo-vm.git Commit:
06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200
By: GitHub mailto:nore...@github.com>>

Cheers,
Andrei


On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier
mailto:thierry.goub...@gmail.com>> wrote:



2017-02-24 14:29 GMT+01:00 Andrei Chis mailto:chisvasileand...@gmail.com>>:



On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier
mailto:thierry.goub...@gmail.com>>
wrote:

Hi Andrei,

2017-02-24 11:31 GMT+01:00 Andrei Chis
mailto:chisvasileand...@gmail.com>>:

Hi Thierry,

Indeed that's the simplest option now that we are using
fast table.

Just now in the case of the Raw view an
OrderedCollection is used to store all displayed elements.
If you display large collections every time you open the
Raw view it will instantiate a collection of size 100k
and instantiate 100k objects of
type GTInspectorIndexedNode. With FastTable we can
lazily load elements so we should be able to remove this
behaviour and the limit. Just we need to make sure it
will play nicely with automatic refresh. There is also
the issue that when expanding an element in the tree if
it's a collection you don't want to expand all elements.


I'm not sure you need to worry too much about that one; in
practical experiments, creating that 100k collection for
viewing (and the associated nodes instances) isn't too
costly (unless creating the GTInspectorIndexedNodes has
hidden costs: I've only experimented with the EyeInspector
framework).


There should be no hidden costs in GTInspectorIndexedNodes.
I made some experiments in the latest Pharo version and opening
the Raw view on an array with one million numbers takes around
120ms when 100k elements are computed.
I'll be curious how much it takes on your machine. To test
update indexableDisplayLimit to 5 in
Object>>#gtInspectorVariableNodesIn: and remove the annotation
from Collection>>#gtInspectorItemsIn: (so that the Items
presentation is not loaded)

arrayLarge := (1 to: 100)

Re: [Pharo-dev] Epicea user experience report

2017-02-24 Thread Igor Stasenko

Epicea is most valuable jewel i ever wished to have in Pharo..
Martin big thanks for your effort to make such a wonderful piece of
software.

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

2017-02-24 Thread Igor Stasenko

Call it Java[tm]
..
..
what? i heard it is quite popular. albeit fuzzy wuzzy
:)

P.S. just call it Pharo-Remote and let it go


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Catalog loading in Spotter

Apparently you do not know the amount of time we have to explain to  
students in FRANCE with internet blocked over a proxy

that No Pharo is not dead.
It is just a time out.

So don't be egoist be adults and use the infrastructure. Use a preference  
in your system.


Stef

Re: [Pharo-dev] Catalog loading in Spotter

The compromise is that people add an expression in one line in their  
startup preferences.

It sounds reasonable to me.

Stef

On Tue, 21 Feb 2017 12:26:43 +0100, Torsten Bergmann   
wrote:

As there were no further objections I guess we should do the following  
steps as a compromise:

 1. We switch back to how it was by selecting Solution A as it is the  
old behavior and the pragmatic approach.
This avoids the confusion, allows to quickly search for the catalog  
items and also renders the videos

valid again.

 2. Pharo 6 is still not released. People can still be testing and if  
this really gives trouble again
(maybe next time in a reproducible way) we can try to fix it/find  
another solution.
In the worst case we can disable it by disabeling the Catalog  
setting (not the GT extension itself)

so it is not confusing or hidden again in the Pharo settings.

I've opened issue https://pharo.fogbugz.com/f/cases/edit/19732 and will  
fix it. Lets see how it goes.

Thanks
T.

Gesendet: Montag, 20. Februar 2017 um 11:27 Uhr
Von: "Sven Van Caekenberghe" 
An: "Pharo Development List" 
Betreff: Re: [Pharo-dev] Catalog loading in Spotter

> On 20 Feb 2017, at 10:30, Pavel Krivanek   
wrote:

>
>
>
> 2017-02-20 10:27 GMT+01:00 Guillermo Polito  
:
> As far as I remember, the main problem was not bandwidth but a  
blocking and non-responsive UI.
> Imagine I'm in the university, or in a company with a proxy. And I  
forget to set the proxy. Then, while spotter tries to fetch catalog  
entries, it would block the image and throw a timeout error some  
minutes after.

>
> So, maybe for the future and besides Ben's C option (which I like) I  
have a

>
> D) Load catalog entries in background in a non-blocking way
>   - and while catalog entries are not yet available, they should not  
be shown

>
> AFIK the main problem was that there was not possilbe to do it  
non-blocking way.

Yes that is true. (It is actually DNS resolving that is blocked in some  
freak case).

But the thing is, the problematic situation only occurs for a very  
small percentage of people, like less than 1%, probably even much less.  
(Remember, nobody can produce a repeatable case for it).

So the question is, is that enough reason to act as if we are still in  
the 90's when internet was a luxury and cut features that depend on it  
? If you have no network today, you're in big trouble anyway. (Again,  
if you turn off your network, no blocking will happen at all, try it).

So what is more important ? The general functionality of the 99.xxx %  
or the unreproducible freak case ?

> -- Pavel
>
>
> Even further, It would make sense a solution that mixes Ben's caching  
with background loading of the catalog entries...

>
> Guille
>
> On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman   
wrote:
> On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann   
wrote:
> > In the past in Pharo it was possible to open Spotter, type in the  
name of a framework/project to load
> > from catalog, perform a search and just hit ENTER to easily install  
the project.

> >
> > This was following the Spotter idea that it is easy to access most  
informations of Pharo

> > with the Spotter tool.
> >
> > There always was and still is a setting in "Settings" -> "Catalog"  
-> "Display catalog projects in Spotter".
> > This setting is ENABLED BY DEFAULT but could be switched off in the  
settings tool or custom preference

> > scripts if this is problematic for someone.
> >
> >
> > Now in Pharo 6 there is an additional class  
"GTSpotterExtensionSettings" to activate/deactivate
> > Spotter extensions. While nearly all of the Spotter extensions are  
enabled the one for the catalog

> > integration is DISABLED BY DEFAULT.
> >
> > This leads to several effects:
> >
> >   1. While in the past it was possible in a fresh Pharo image to  
search and install out of
> >  the box it is (as of today in the not yet released Pharo 6)  
not possible anymore to quickly

> >  start by searching and installing from catalog using Spotter.
> >
> >   2. It is very confusing that in the settings "Display catalog  
projects in Spotter" is enabled but a search
> >  in Spotter gives no results. Most people will not not know  
about the second setting and easily

> >  get lost and think this behavior is just broken.
> >  Also this second setting for the Spotter extension is much  
more hidden between all the other

> >  Spotter extension enablements very and hard to find.
>
> Generally its not good to have two settings for the one thing.
>
> >
> >   3. Several of my youtube videos demonstrating Goodies like  
DesktopManager, QuickAccess,
> >  MessageFlowBrowser, ... directly start by loading the tools  
from Spotter. Anyone newbee who will
> >  follow these will not only be confused - but also stuck in  
trying Pharo when he learns

> >  from these videos.
>
> UI things do evolve and videos date.  But these seem worthwhile to  
keep

Re: [Pharo-dev] Catalog loading in Spotter


Guillermo

such people do not know what is ti teach in the university with a fucking  
proxy like you and me.

It is super easy when you are not expose to the view of newbies.

PHARO IS NOT WELL PACKAGED guys. Try to get out our confort zone.
The world is different and working.

Stef



As far as I remember, the main problem was not bandwidth but a blocking  
and non-responsive UI.
Imagine I'm in the university, or in a company with a proxy. And I  
forget to set the proxy. Then, while spotter tries to fetch catalog  
entries, it would block the image and throw a timeout error >some  
minutes after.


So, maybe for the future and besides Ben's C option (which I like) I  
have a


D) Load catalog entries in background in a non-blocking way
 - and while catalog entries are not yet available, they should not be  
shown


Even further, It would make sense a solution that mixes Ben's caching  
with background loading of the catalog entries...  
Guille


On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman  wrote:
On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann   
wrote:
In the past in Pharo it was possible to open Spotter, type in the name  
of a framework/project to load
from catalog, perform a search and just hit ENTER to easily install  
the project.


This was following the Spotter idea that it is easy to access most  
informations of Pharo

with the Spotter tool.

There always was and still is a setting in "Settings" -> "Catalog" ->  
"Display catalog projects in Spotter".
This setting is ENABLED BY DEFAULT but could be switched off in the  
settings tool or custom preference

scripts if this is problematic for someone.


Now in Pharo 6 there is an additional class  
"GTSpotterExtensionSettings" to activate/deactivate
Spotter extensions. While nearly all of the Spotter extensions are  
enabled the one for the catalog

integration is DISABLED BY DEFAULT.

This leads to several effects:

  1. While in the past it was possible in a fresh Pharo image to  
search and install out of
 the box it is (as of today in the not yet released Pharo 6) not  
possible anymore to quickly

 start by searching and installing from catalog using Spotter.

  2. It is very confusing that in the settings "Display catalog  
projects in Spotter" is enabled but a search
 in Spotter gives no results. Most people will not not know about  
the second setting and easily

 get lost and think this behavior is just broken.
 Also this second setting for the Spotter extension is much more  
hidden between all the other

 Spotter extension enablements very and hard to find.


Generally its not good to have two settings for the one thing.



  3. Several of my youtube videos demonstrating Goodies like  
DesktopManager, QuickAccess,
 MessageFlowBrowser, ... directly start by loading the tools from  
Spotter. Anyone newbee who will
 follow these will not only be confused - but also stuck in trying  
Pharo when he learns

 from these videos.


UI things do evolve and videos date.  But these seem worthwhile to keep  
current.




 I was asked several times on Slack and via Mail from people who  
were not able to reproduce ... this
 is really annyoing. Especially this gives the wrong impression to  
newbees. Things should be easy

 not complicated.

To my knowledge disabling the Spotter search in Pharo 6 came up due to  
some Pharo teaching in regions

with slow internet connection.


This made sense at the time.  It is a worse first impression if UI
lags when this central part of the UI is interfaced.
How often would it access the network?  Every time? Or did it cache
the result for a day, etc?

I understand that we would like to support these Pharo users too as  
best
as possible in their out of the box experience ... but (without being  
able to prove) I think that 90% or
more Pharo users have a regular internet connection. Otherwise it  
would be hard to work with updates,

project loading, PharoLauncher, STHub or Iceberg/GitHub.

Also my own personal experience is that even on low bandwidth network  
this Catalog Spotter search for
me was always fast enough (as I often use Pharo in trains with slow  
connections or on a Pi with slow
connections and less processing power). I do not know about all others  
from the community.


I invested hours in the past in developing and introducing the initial  
configuration browser to Pharo,
later improved and helped shaping its replacement CatalogBrowser, also  
contributed this spotter search
for the catalog items so things are more accessible, easy and  
enjoyable. That's why I also invested

hours in udpating configs or pushing you to put things into catalog.

Because accessibility is key. Only when things are easy to access and  
understandable people will

enjoy Pharo.

Currently in an out-of the box image this easy access to the projects  
via Spotter is blocked.
Additionally I have to explain to anyone who asks me that there is a  
second non-obvious/more hid

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 Thread Igor Stasenko

On 24 February 2017 at 21:01, Pavel Krivanek 
wrote:

>
> 2017-02-24 17:17 GMT+01:00 Denis Kudriashov :
>
>>
>> 2017-02-24 16:36 GMT+01:00 Pavel Krivanek :
>>
>>> The "guest" object memory runs in a special virtual machine simulator
>>> during the bootstrapping. That simulator uses AST Interpreter to execute
>>> the code inside the guest environment before it is installed for real. It
>>> uses own special kind of proxies and tricks to do it. The current bootstrap
>>> cannot run without class builder in the guest environment, but...
>>>
>>>
 And how much smaller could the image get if the class builder was
 removed.

>>>
>>> ...Guille in his thesis tried different approaches and he was able to
>>> produce extremely small images  (~10 KiB) that did for example only a sum
>>> of two numbers.
>>>
>>
>> Is it future approach for bootstrap?
>> How faster or slower bootstrap process with it?
>>
>
> That's more question for Guille, but I do not think we will adopt this
> approach of bootstrapping in near future because it needs to be updated for
> the Spur format and it needs a special VM modifications. And the question
> is how much is it really needed because if you want to do something with
> the image, you will anyway need most of methods needed for the class
> builder like basic strings and collections support.
>
>
I think, you can shrink image even more, by running something after booting
it to remove ClassBuilder & co, if you don't need to create classes etc.

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Catalog loading in Spotter

You are telling me that expert developers cannot have a script that  
automatically
set this. I cannot believe. I hope that your confort zone is not too  
disruptive.


I'm really sad. I'm currently writing a book for newbies and I spent my  
morning talking to people

in liberia.

Poor guys.

Stef

Re: [Pharo-dev] Catalog loading in Spotter

2017-02-24 Thread Sven Van Caekenberghe


> On 24 Feb 2017, at 18:56, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 24 Feb 2017, at 18:14, Ben Coman  wrote:
>> 
>> 
>> 
>> On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe  wrote:
>> 
>>> On 20 Feb 2017, at 10:30, Pavel Krivanek  wrote:
>>> 
>>> 
>>> 
>>> 2017-02-20 10:27 GMT+01:00 Guillermo Polito :
>>> As far as I remember, the main problem was not bandwidth but a blocking and 
>>> non-responsive UI.
>>> Imagine I'm in the university, or in a company with a proxy. And I forget 
>>> to set the proxy. Then, while spotter tries to fetch catalog entries, it 
>>> would block the image and throw a timeout error some minutes after.
>>> 
>>> So, maybe for the future and besides Ben's C option (which I like) I have a
>>> 
>>> D) Load catalog entries in background in a non-blocking way
>>>  - and while catalog entries are not yet available, they should not be shown
>>> 
>>> AFIK the main problem was that there was not possilbe to do it non-blocking 
>>> way.
>> 
>> Yes that is true. (It is actually DNS resolving that is blocked in some 
>> freak case).
>> 
>> In   sqUnixSocket.c   I read...
>> * Notes:
>> *  Sockets are completely asynchronous, but the resolver is still 
>> synchronous.
>> 
>> So does this mean that if for any reason the resolver primitive takes a long 
>> time to respond,
>> the whole VM is blocked? Thus forking the Catalog loading in another thread 
>> would have no benefit?
> 
> Yes and yes.
> 
>> Would having the resolver coded purely in-Image behave better? 
> 
> Yes (probably).
> 
>> So a slow name resolution would not hold up the whole image if it happened 
>> in a forked thread.
> 
> Yes.
> 
>> I found such an implementation in OpenCobalt and after some minor cleanup 
>> basic operations work fine.
>> 
>> http://smalltalkhub.com/#!/~BenComan/DNS/
> 
> Well, I did one myself too (I have not looked at the one above, I will), but 
> my conclusion was that it is not that difficult to get basic lookup working, 
> but edge cases (like concurrent requests with intermixed answers) are not so 
> easy.
> 
> There is also a chicken/egg problem: what DNS resolver (host) will you 
> contact ? How to find out the one configured by your OS ? My idea was to use 
> the Google ones (8.8.8.8), but there is also a more open one (80.80.80.80) 
> and probably others.
> 
> We are often accused of reinventing the wheel and carrying the burden of 
> maintaining all that infrastructure. Doing our own DNS client would add to 
> that. 
> 
> But I like the general idea, the question is one about development risk.

So Ben,

I could not get the code to run (on Pharo 6) using UDP, it remained stuck on 
sending the UDP packet, which is really weird.

I found my old code, turns out it was based on the same message/packets 
hierarchy. And it still worked.

I committed it to your repo:

===
Name: Net-Protocols-DNS-SvenVanCaekenberghe.15
Author: SvenVanCaekenberghe
Time: 24 February 2017, 8:08:54.299786 pm
UUID: 9b8fa332-ad05-0d00-8577-5adb00d43870
Ancestors: Net-Protocols-DNS-BenComan.14

Added NeoDNSClient to Net-Protocols-DNS-Experimental
===

You should be able to do 

  NeoDNSClient default addressForName: 'stfx.eu'.

There is no caching yet, but there is a simple #beThreadSafe provided.

(My other comments remain valid, also for my own code).

Sven

>> cheers -ben
>> 
>> But the thing is, the problematic situation only occurs for a very small 
>> percentage of people, like less than 1%, probably even much less. (Remember, 
>> nobody can produce a repeatable case for it).
>> 
>> So the question is, is that enough reason to act as if we are still in the 
>> 90's when internet was a luxury and cut features that depend on it ? If you 
>> have no network today, you're in big trouble anyway. (Again, if you turn off 
>> your network, no blocking will happen at all, try it).
>> 
>> So what is more important ? The general functionality of the 99.xxx % or the 
>> unreproducible freak case ?

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 17:17 GMT+01:00 Denis Kudriashov :

>
> 2017-02-24 16:36 GMT+01:00 Pavel Krivanek :
>
>> The "guest" object memory runs in a special virtual machine simulator
>> during the bootstrapping. That simulator uses AST Interpreter to execute
>> the code inside the guest environment before it is installed for real. It
>> uses own special kind of proxies and tricks to do it. The current bootstrap
>> cannot run without class builder in the guest environment, but...
>>
>>
>>> And how much smaller could the image get if the class builder was
>>> removed.
>>>
>>
>> ...Guille in his thesis tried different approaches and he was able to
>> produce extremely small images  (~10 KiB) that did for example only a sum
>> of two numbers.
>>
>
> Is it future approach for bootstrap?
> How faster or slower bootstrap process with it?
>

That's more question for Guille, but I do not think we will adopt this
approach of bootstrapping in near future because it needs to be updated for
the Spur format and it needs a special VM modifications. And the question
is how much is it really needed because if you want to do something with
the image, you will anyway need most of methods needed for the class
builder like basic strings and collections support.

Re: [Pharo-dev] Catalog loading in Spotter

2017-02-24 Thread Sven Van Caekenberghe


> On 24 Feb 2017, at 18:14, Ben Coman  wrote:
> 
> 
> 
> On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe  wrote:
> 
> > On 20 Feb 2017, at 10:30, Pavel Krivanek  wrote:
> >
> >
> >
> > 2017-02-20 10:27 GMT+01:00 Guillermo Polito :
> > As far as I remember, the main problem was not bandwidth but a blocking and 
> > non-responsive UI.
> > Imagine I'm in the university, or in a company with a proxy. And I forget 
> > to set the proxy. Then, while spotter tries to fetch catalog entries, it 
> > would block the image and throw a timeout error some minutes after.
> >
> > So, maybe for the future and besides Ben's C option (which I like) I have a
> >
> > D) Load catalog entries in background in a non-blocking way
> >   - and while catalog entries are not yet available, they should not be 
> > shown
> >
> > AFIK the main problem was that there was not possilbe to do it non-blocking 
> > way.
> 
> Yes that is true. (It is actually DNS resolving that is blocked in some freak 
> case).
> 
> In   sqUnixSocket.c   I read...
>  * Notes:
>  *  Sockets are completely asynchronous, but the resolver is still 
> synchronous.
> 
> So does this mean that if for any reason the resolver primitive takes a long 
> time to respond,
> the whole VM is blocked? Thus forking the Catalog loading in another thread 
> would have no benefit?

Yes and yes.

> Would having the resolver coded purely in-Image behave better? 

Yes (probably).

> So a slow name resolution would not hold up the whole image if it happened in 
> a forked thread.

Yes.

> I found such an implementation in OpenCobalt and after some minor cleanup 
> basic operations work fine.
> 
> http://smalltalkhub.com/#!/~BenComan/DNS/

Well, I did one myself too (I have not looked at the one above, I will), but my 
conclusion was that it is not that difficult to get basic lookup working, but 
edge cases (like concurrent requests with intermixed answers) are not so easy.

There is also a chicken/egg problem: what DNS resolver (host) will you contact 
? How to find out the one configured by your OS ? My idea was to use the Google 
ones (8.8.8.8), but there is also a more open one (80.80.80.80) and probably 
others.

We are often accused of reinventing the wheel and carrying the burden of 
maintaining all that infrastructure. Doing our own DNS client would add to 
that. 

But I like the general idea, the question is one about development risk.

> cheers -ben
>  
> But the thing is, the problematic situation only occurs for a very small 
> percentage of people, like less than 1%, probably even much less. (Remember, 
> nobody can produce a repeatable case for it).
> 
> So the question is, is that enough reason to act as if we are still in the 
> 90's when internet was a luxury and cut features that depend on it ? If you 
> have no network today, you're in big trouble anyway. (Again, if you turn off 
> your network, no blocking will happen at all, try it).
> 
> So what is more important ? The general functionality of the 99.xxx % or the 
> unreproducible freak case ?

Re: [Pharo-dev] Catalog loading in Spotter

On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe  wrote:

>
> > On 20 Feb 2017, at 10:30, Pavel Krivanek 
> wrote:
> >
> >
> >
> > 2017-02-20 10:27 GMT+01:00 Guillermo Polito :
> > As far as I remember, the main problem was not bandwidth but a blocking
> and non-responsive UI.
> > Imagine I'm in the university, or in a company with a proxy. And I
> forget to set the proxy. Then, while spotter tries to fetch catalog
> entries, it would block the image and throw a timeout error some minutes
> after.
> >
> > So, maybe for the future and besides Ben's C option (which I like) I
> have a
> >
> > D) Load catalog entries in background in a non-blocking way
> >   - and while catalog entries are not yet available, they should not be
> shown
> >
> > AFIK the main problem was that there was not possilbe to do it
> non-blocking way.
>
> Yes that is true. (It is actually DNS resolving that is blocked in some
> freak case).
>

In   sqUnixSocket.c   I read...
 * Notes:
 *  Sockets are completely asynchronous, but the resolver is still
synchronous.

So does this mean that if for any reason the resolver primitive takes a
long time to respond,
the whole VM is blocked? Thus forking the Catalog loading in another thread
would have no benefit?

Would having the resolver coded purely in-Image behave better?
So a slow name resolution would not hold up the whole image if it happened
in a forked thread.
I found such an implementation in OpenCobalt and after some minor cleanup
basic operations work fine.

http://smalltalkhub.com/#!/~BenComan/DNS/

cheers -ben


> But the thing is, the problematic situation only occurs for a very small
> percentage of people, like less than 1%, probably even much less.
> (Remember, nobody can produce a repeatable case for it).
>
> So the question is, is that enough reason to act as if we are still in the
> 90's when internet was a luxury and cut features that depend on it ? If you
> have no network today, you're in big trouble anyway. (Again, if you turn
> off your network, no blocking will happen at all, try it).
>
> So what is more important ? The general functionality of the 99.xxx % or
> the unreproducible freak case ?
>
>

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

2017-02-24 Thread Andreas Wacknitz

I second this wholeheartedly!
Everything that is used outside Pharo could have a fancy name.
For internal tools and frameworks this is IMO really irritating and
repellent.

It is like talking in argot and creates high walls around Pharo.

Andreas

Am 24.02.17 um 17:18 schrieb Brad Selfridge:

I understand that if a developer is building a standalone application, (like
Windows, Apache, Slack, Git, .. PHARO !!! ), then a fuzzy-wuzzy name may
make sense. But, there are so many packages that are built for Pharo/Squeak
use only, that have cryptic names and no descriptions. This drives me crazy.
I see all these package names spewn about and I have no idea what they are.
I look on the Pharo website - no explanation. I look on Git - often times
little to no explanation. I look on SmalltalkHub - little to no
explanation...etc. I look on Catalog Browser - absolutely NO explanation.
The only way to find out is start texting message boards or load the code
and study the crap out of it just trying to figure out that - "oops, I
didn't really want that loaded at all".

With that said, the creator has the right to name their creation anything
they want. Just understand, that we ARE wanting to grow our exposure and the
we need to make this as easy and pain free as possible.

-
Brad Selfridge
--
View this message in context:
http://forum.world.st/Any-idea-for-a-cool-name-for-the-remote-tool-suite-tp4932008p4935822.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

On Fri, Feb 24, 2017 at 11:36 PM, Pavel Krivanek 
wrote:

>
>
> 2017-02-24 15:58 GMT+01:00 Ben Coman :
>
>>
>>
>> On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek > > wrote:
>>
>>> Hi,
>>>
>>> I have published a short video of the Pharo bootstrapping from a Ring
>>> model that is browsed and modified by the Calypso browser.
>>>
>>> https://www.youtube.com/watch?v=QguZSPKo7-w
>>>
>>> No audio, please enable subtitles for the description.
>>>
>>>
>> Wow wow wow !! Super-cool !!
>> I had to watch it a few times.
>> 314k image is pretty impressive.
>>
>> Just to clarify, Calypso is not connected to a remote image but browses
>> the bootstrap source code loaded into a Ring Environment?
>>
>
>
> Yes, Calypso browses an off-line source code loaded into the Ring
> environment.
>
>
>
>>  (btw, should we call this a "guest environment"?)
>>
>
> It is possible to open Calypso on a Ring model that takes data from the
> current image so in that case it would be confusing:-)
>

I meant only for the purpose of discussing bootstrap, not Calypso in
general.  :)

The rest of your responses made things clear. Thx.
cheers -ben


>
>
>
>>
>> When you show the previously opened window "Methods with a string aText
>> 'Smalltalk run' ..."
>> showing PBImageBuilder50 >> initializeImage,
>> that was opened before you created the new Ring Environment and Calypso
>> was opened,
>> so can I presume it was opened on a similar Ring Environment created
>> earlier?
>>
>
> It is a standard Nautilus window on the code in the image that does the
> bootstrapping. For the standard bootstrap it does much more things. See:
> https://github.com/guillep/pharo-core/blob/dfbfb77844a31701da6e49691af2a0
> 5ad55b4bc6/bootstrap/src/Pharo30Bootstrap.package/PBImageBuilder50.class/
> instance/initializeImage.st
>
>
>>
>> There were no processes in the guest image prior to doing this...
>> process := objectSpace
>> createProcessWithPriority: 40
>> doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run').
>> objectSpace installActiveProcess: process.
>> so this was a single process Image?
>>
>
> Yes, see the method above
>
>
>>
>> You say "The image must contain support for the class builder to be able
>> to be bootstrapped."
>> When you create the SmalltalkImage>>run method in the guest environment,
>> is that actually *running* to compiled as normal using its class builder?
>>
>
> No, when I create the method, only the source code is set in the Ring
> model. The model is "dead". The real installation of the method into the
> generated object memory is done during the bootstrapping.
>
>
>>
>> How difficult would it be for the guest image to invoke class builder via
>> seamless in the host image?
>>
>
> The "guest" object memory runs in a special virtual machine simulator
> during the bootstrapping. That simulator uses AST Interpreter to execute
> the code inside the guest environment before it is installed for real. It
> uses own special kind of proxies and tricks to do it. The current bootstrap
> cannot run without class builder in the guest environment, but...
>
>
>> And how much smaller could the image get if the class builder was removed.
>>
>
> ...Guille in his thesis tried different approaches and he was able to
> produce extremely small images  (~10 KiB) that did for example only a sum
> of two numbers.
>
> https://guillep.github.io/files/publications/Poli15Thesis.pdf
>
>
>>
>> It could be cool if this bootstrap creation process was integrated in
>> PharoLauncher as a GUI tool.  Then later the ability to download these
>> mini-image to an embedded controller could be added.
>>
>
>> cheers -ben
>>
>> P.S. Could you maybe blog this also, to make it easier to replicate and
>> copy-paste the Playground text.
>>
>
>

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

2017-02-24 Thread Brad Selfridge

I understand that if a developer is building a standalone application, (like
Windows, Apache, Slack, Git, .. PHARO !!! ), then a fuzzy-wuzzy name may
make sense. But, there are so many packages that are built for Pharo/Squeak
use only, that have cryptic names and no descriptions. This drives me crazy.
I see all these package names spewn about and I have no idea what they are.
I look on the Pharo website - no explanation. I look on Git - often times
little to no explanation. I look on SmalltalkHub - little to no
explanation...etc. I look on Catalog Browser - absolutely NO explanation.
The only way to find out is start texting message boards or load the code
and study the crap out of it just trying to figure out that - "oops, I
didn't really want that loaded at all". 

With that said, the creator has the right to name their creation anything
they want. Just understand, that we ARE wanting to grow our exposure and the
we need to make this as easy and pain free as possible. 



-
Brad Selfridge
--
View this message in context: 
http://forum.world.st/Any-idea-for-a-cool-name-for-the-remote-tool-suite-tp4932008p4935822.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 16:36 GMT+01:00 Pavel Krivanek :

> The "guest" object memory runs in a special virtual machine simulator
> during the bootstrapping. That simulator uses AST Interpreter to execute
> the code inside the guest environment before it is installed for real. It
> uses own special kind of proxies and tricks to do it. The current bootstrap
> cannot run without class builder in the guest environment, but...
>
>
>> And how much smaller could the image get if the class builder was removed.
>>
>
> ...Guille in his thesis tried different approaches and he was able to
> produce extremely small images  (~10 KiB) that did for example only a sum
> of two numbers.
>

Is it future approach for bootstrap?
How faster or slower bootstrap process with it?

Re: [Pharo-dev] Epicea - showing latest lost changes

Except you may need to exclude the last few changes which made your image
crash.
Maybe there could be two buttons  "1. Select lost changes" and "2. Restore
selected"
which gives you the opportunity to manually deselect between the steps.
Step 1 might select only the latest of each method, without the need to
filter.

cheers -ben

On Fri, Feb 24, 2017 at 11:04 PM, Yuriy Tymchuk 
wrote:

> I have one more suggestion for Epicea. When the window pops up I’d like to
> have a big “RESTORE” button to reapply all the changes. I think it will be
> also more user friendly, as how should an newcomer know that he has to
> select all the items in the list and use the context menu.
>
> Cheers.
> Uko
>
>
> On 24 Feb 2017, at 08:33, stepharong  wrote:
>
> Hi martin
>
> Thanks for our constant improvement of epicea.
> In VW they have a nice way to filter
>
> you can filter the entitiies
>  doit or not
>  method or not
>  packages or not
> and you can deselect a selected item.
>
> this way you can say I do not want any doit except this one.
>
>
>
> On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias 
> wrote:
>
> Hi. Does this report match your idea?
> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters
>
> Martin
>
> On Thu, Feb 23, 2017 at 3:35 PM, stepharong  wrote:
>
>> I agree :)
>>
>> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman 
>> wrote:
>>
>> One thing I am missing from Epicea that I used to be able to do
>> is being able to filter out old changes.  If I've been thrashing
>> some method back and forth between a few implementations,
>> often I don't want to see *all* the old changes,only the latest ones.
>>
>> An option to restore old versions would also be nice, but I don't think
>> that feature existed previously.
>>
>> cheers -ben
>>
>>
>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
>
>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>
>

Re: [Pharo-dev] Raw pane on byteStrings

Hi Thierry,

Strangely enough I'm getting different times on my machine
Just to start from the same baseline in a fresh Pharo 60411 image with no
changes to any of the inspectors over a series of runs I get:

array := (1 to: 100) asArray.
[array inspect] timeToRun.   "0:00:00:00.145"
[GTInspector inspect: array] timeToRun. "0:00:00:00.031"

If I change indexableDisplayLimit to 5 and remove the Items view then I
get:

[GTInspector inspect: array] timeToRun.  "0:00:00:00.124"

I'm really interested in seeing what makes GTInspector slower on your
machine. Did you do other optimizations to SpecInspector?
I'm using a MacBook Pro Retina - 2.8 GHz Intel Core i7

Pharo VM version:
CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid:
16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880
uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Oct 10 2016
g...@github.com:pharo-project/pharo-vm.git Commit:
06744effac0f0aa3b4b32e17636448f9d51d6707 Date: 2016-09-30 08:40:43 +0200
By: GitHub 

Cheers,
Andrei

On Fri, Feb 24, 2017 at 3:24 PM, Thierry Goubier 
wrote:

>
>
> 2017-02-24 14:29 GMT+01:00 Andrei Chis :
>
>>
>>
>> On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> Hi Andrei,
>>>
>>> 2017-02-24 11:31 GMT+01:00 Andrei Chis :
>>>
 Hi Thierry,

 Indeed that's the simplest option now that we are using fast table.

 Just now in the case of the Raw view an OrderedCollection is used to
 store all displayed elements.
 If you display large collections every time you open the Raw view it
 will instantiate a collection of size 100k and instantiate 100k
 objects of type GTInspectorIndexedNode. With FastTable we can lazily load
 elements so we should be able to remove this behaviour and the limit. Just
 we need to make sure it will play nicely with automatic refresh. There is
 also the issue that when expanding an element in the tree if it's a
 collection you don't want to expand all elements.

>>>
>>> I'm not sure you need to worry too much about that one; in practical
>>> experiments, creating that 100k collection for viewing (and the associated
>>> nodes instances) isn't too costly (unless creating the
>>> GTInspectorIndexedNodes has hidden costs: I've only experimented with the
>>> EyeInspector framework).
>>>
>>
>> There should be no hidden costs in GTInspectorIndexedNodes.
>> I made some experiments in the latest Pharo version and opening the Raw
>> view on an array with one million numbers takes around 120ms when 100k
>> elements are computed.
>> I'll be curious how much it takes on your machine. To test update
>> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
>> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that
>> the Items presentation is not loaded)
>>
>> arrayLarge := (1 to: 100) asArray.
>> arrayLarge inspect.
>>
>
> This is the values I get on my work laptop (core i3-2350M 2.30 Ghz); both
> inspectors displays 100k elements.
>
> (1 to: 100) asArray in: [ :s |  [s inspect] timeToRun] 0:00:00:00.064
> (1 to: 100) asArray in: [:s | [GTInspector inspect: s] timeToRun]
> 0:00:00:00.381
>
> Pharo 6 60411
>
>
>>
>>
>>>
>>> Opening the tree with all elements works fine in my experiments. Tuning
>>> scrolling as done in Bloc is necessary, however.
>>>
>>>

 I'm looking now on a lazy data source for FastTable that plays nicely
 with GTInspector. Let's see how it will go. Help is always welcomed :)

>>>
>>> As I said: do not overoptimize that part... just remove that limitation
>>> on the raw view and measure.
>>>
>>
>> If I measure the Items view on the previous array it takes around 35ms.
>> What I'd like to have is the same opening time for the Items view on
>> large Sets and Dictionaries.
>>
>
> On my machine, the experiment is that displaying the set is fast, but the
> system becomes totally unresponsive... which may be an issue with the self
> refresh of the inspector. Yes, it was the culprit.
>
> (1 to: 100) asSet in: [ :s |  [s inspect] timeToRun] 0:00:00:00.034
> (1 to: 100) asSet in: [:s | [GTInspector inspect: s] timeToRun]
> 0:00:00:00.199
>
> Regards,
>
> Thierry
>
>
>>
>>
>>>
>>>

 I think I used the word paginator in the wrong way. If you have a very
 large collection (millions of elements) I do not want to scroll through
 elements but most likely jump to a certain element or view just a subset of
 all elements. Not really add a paginator like in web pages.

>>>
>>> Ok, millions of elements is a bit out of my scope... I'll look for
>>> filtering then.
>>>
>>
>> Yes, definitely filtering is the way to go there :)
>>
>> Cheers,
>> Andrei
>>
>>
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>>

 Cheers,
 Andrei

 On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier <
 thierry.goub...@gmail.com> wrote:

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 16:31 GMT+01:00 Martin Dias :

> Great! any idea how far is new Ring from replacing old Ring?
>

In Pharo 7. Right now the new version can live in the image next to the old
one.


>
> Martín
>
> On Fri, Feb 24, 2017 at 11:58 AM, Ben Coman  wrote:
>
>>
>>
>> On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek > > wrote:
>>
>>> Hi,
>>>
>>> I have published a short video of the Pharo bootstrapping from a Ring
>>> model that is browsed and modified by the Calypso browser.
>>>
>>> https://www.youtube.com/watch?v=QguZSPKo7-w
>>>
>>> No audio, please enable subtitles for the description.
>>>
>>>
>> Wow wow wow !! Super-cool !!
>> I had to watch it a few times.
>> 314k image is pretty impressive.
>>
>> Just to clarify, Calypso is not connected to a remote image but browses
>> the bootstrap source code loaded into a Ring Environment?  (btw, should we
>> call this a "guest environment"?)
>>
>> When you show the previously opened window "Methods with a string aText
>> 'Smalltalk run' ..."
>> showing PBImageBuilder50 >> initializeImage,
>> that was opened before you created the new Ring Environment and Calypso
>> was opened,
>> so can I presume it was opened on a similar Ring Environment created
>> earlier?
>>
>> There were no processes in the guest image prior to doing this...
>> process := objectSpace
>> createProcessWithPriority: 40
>> doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run').
>> objectSpace installActiveProcess: process.
>> so this was a single process Image?
>>
>> You say "The image must contain support for the class builder to be able
>> to be bootstrapped."
>> When you create the SmalltalkImage>>run method in the guest environment,
>> is that actually *running* to compiled as normal using its class builder?
>>
>> How difficult would it be for the guest image to invoke class builder via
>> seamless in the host image?
>> And how much smaller could the image get if the class builder was removed.
>>
>> It could be cool if this bootstrap creation process was integrated in
>> PharoLauncher as a GUI tool.  Then later the ability to download these
>> mini-image to an embedded controller could be added.
>>
>> cheers -ben
>>
>> P.S. Could you maybe blog this also, to make it easier to replicate and
>> copy-paste the Playground text.
>>
>
>

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 Thread Martin Dias

Great! any idea how far is new Ring from replacing old Ring?

Martín

On Fri, Feb 24, 2017 at 11:58 AM, Ben Coman  wrote:

>
>
> On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek 
> wrote:
>
>> Hi,
>>
>> I have published a short video of the Pharo bootstrapping from a Ring
>> model that is browsed and modified by the Calypso browser.
>>
>> https://www.youtube.com/watch?v=QguZSPKo7-w
>>
>> No audio, please enable subtitles for the description.
>>
>>
> Wow wow wow !! Super-cool !!
> I had to watch it a few times.
> 314k image is pretty impressive.
>
> Just to clarify, Calypso is not connected to a remote image but browses
> the bootstrap source code loaded into a Ring Environment?  (btw, should we
> call this a "guest environment"?)
>
> When you show the previously opened window "Methods with a string aText
> 'Smalltalk run' ..."
> showing PBImageBuilder50 >> initializeImage,
> that was opened before you created the new Ring Environment and Calypso
> was opened,
> so can I presume it was opened on a similar Ring Environment created
> earlier?
>
> There were no processes in the guest image prior to doing this...
> process := objectSpace
> createProcessWithPriority: 40
> doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run').
> objectSpace installActiveProcess: process.
> so this was a single process Image?
>
> You say "The image must contain support for the class builder to be able
> to be bootstrapped."
> When you create the SmalltalkImage>>run method in the guest environment,
> is that actually *running* to compiled as normal using its class builder?
>
> How difficult would it be for the guest image to invoke class builder via
> seamless in the host image?
> And how much smaller could the image get if the class builder was removed.
>
> It could be cool if this bootstrap creation process was integrated in
> PharoLauncher as a GUI tool.  Then later the ability to download these
> mini-image to an embedded controller could be added.
>
> cheers -ben
>
> P.S. Could you maybe blog this also, to make it easier to replicate and
> copy-paste the Playground text.
>

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 15:58 GMT+01:00 Ben Coman :

>
>
> On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek 
> wrote:
>
>> Hi,
>>
>> I have published a short video of the Pharo bootstrapping from a Ring
>> model that is browsed and modified by the Calypso browser.
>>
>> https://www.youtube.com/watch?v=QguZSPKo7-w
>>
>> No audio, please enable subtitles for the description.
>>
>>
> Wow wow wow !! Super-cool !!
> I had to watch it a few times.
> 314k image is pretty impressive.
>
> Just to clarify, Calypso is not connected to a remote image but browses
> the bootstrap source code loaded into a Ring Environment?
>

Yes, Calypso browses an off-line source code loaded into the Ring
environment.

>  (btw, should we call this a "guest environment"?)
>

It is possible to open Calypso on a Ring model that takes data from the
current image so in that case it would be confusing:-)

>
> When you show the previously opened window "Methods with a string aText
> 'Smalltalk run' ..."
> showing PBImageBuilder50 >> initializeImage,
> that was opened before you created the new Ring Environment and Calypso
> was opened,
> so can I presume it was opened on a similar Ring Environment created
> earlier?
>

It is a standard Nautilus window on the code in the image that does the
bootstrapping. For the standard bootstrap it does much more things. See:
https://github.com/guillep/pharo-core/blob/dfbfb77844a31701da6e49691af2a05ad55b4bc6/bootstrap/src/Pharo30Bootstrap.package/PBImageBuilder50.class/instance/initializeImage.st

>
> There were no processes in the guest image prior to doing this...
> process := objectSpace
> createProcessWithPriority: 40
> doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run').
> objectSpace installActiveProcess: process.
> so this was a single process Image?
>

Yes, see the method above

>
> You say "The image must contain support for the class builder to be able
> to be bootstrapped."
> When you create the SmalltalkImage>>run method in the guest environment,
> is that actually *running* to compiled as normal using its class builder?
>

No, when I create the method, only the source code is set in the Ring
model. The model is "dead". The real installation of the method into the
generated object memory is done during the bootstrapping.

>
> How difficult would it be for the guest image to invoke class builder via
> seamless in the host image?
>

The "guest" object memory runs in a special virtual machine simulator
during the bootstrapping. That simulator uses AST Interpreter to execute
the code inside the guest environment before it is installed for real. It
uses own special kind of proxies and tricks to do it. The current bootstrap
cannot run without class builder in the guest environment, but...

> And how much smaller could the image get if the class builder was removed.
>

...Guille in his thesis tried different approaches and he was able to
produce extremely small images  (~10 KiB) that did for example only a sum
of two numbers.

https://guillep.github.io/files/publications/Poli15Thesis.pdf

>
> It could be cool if this bootstrap creation process was integrated in
> PharoLauncher as a GUI tool.  Then later the ability to download these
> mini-image to an embedded controller could be added.
>

> cheers -ben
>
> P.S. Could you maybe blog this also, to make it easier to replicate and
> copy-paste the Playground text.
>

Re: [Pharo-dev] Epicea - showing latest lost changes

2017-02-24 Thread Yuriy Tymchuk

I have one more suggestion for Epicea. When the window pops up I’d like to have 
a big “RESTORE” button to reapply all the changes. I think it will be also more 
user friendly, as how should an newcomer know that he has to select all the 
items in the list and use the context menu.

Cheers.
Uko

> On 24 Feb 2017, at 08:33, stepharong  wrote:
> 
> Hi martin
> 
> Thanks for our constant improvement of epicea. 
> In VW they have a nice way to filter
> 
> you can filter the entitiies
>  doit or not
>  method or not
>  packages or not
> and you can deselect a selected item. 
> 
> this way you can say I do not want any doit except this one. 
> 
> 
> 
> On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias  wrote:
> 
> Hi. Does this report match your idea? 
> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters 
>  
> 
> Martin
> 
> On Thu, Feb 23, 2017 at 3:35 PM, stepharong  > wrote:
> I agree :)
> 
> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman  > wrote:
> 
> One thing I am missing from Epicea that I used to be able to do
> is being able to filter out old changes.  If I've been thrashing 
> some method back and forth between a few implementations, 
> often I don't want to see *all* the old changes,only the latest ones.  
> 
> An option to restore old versions would also be nice, but I don't think that 
> feature existed previously.
> 
> cheers -ben
> 
> 
> 
> --
> Using Opera's mail client: http://www.opera.com/mail/ 
> 
> 
> 
> 
> --
> Using Opera's mail client: http://www.opera.com/mail/ 
>

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

On Fri, Feb 24, 2017 at 8:36 PM, Pavel Krivanek 
wrote:

> Hi,
>
> I have published a short video of the Pharo bootstrapping from a Ring
> model that is browsed and modified by the Calypso browser.
>
> https://www.youtube.com/watch?v=QguZSPKo7-w
>
> No audio, please enable subtitles for the description.
>
>
Wow wow wow !! Super-cool !!
I had to watch it a few times.
314k image is pretty impressive.

Just to clarify, Calypso is not connected to a remote image but browses the
bootstrap source code loaded into a Ring Environment?  (btw, should we call
this a "guest environment"?)

When you show the previously opened window "Methods with a string aText
'Smalltalk run' ..."
showing PBImageBuilder50 >> initializeImage,
that was opened before you created the new Ring Environment and Calypso was
opened,
so can I presume it was opened on a similar Ring Environment created
earlier?

There were no processes in the guest image prior to doing this...
process := objectSpace
createProcessWithPriority: 40
doing: ('Smalltalk primitiveGarbageCollect. Smalltalk run').
objectSpace installActiveProcess: process.
so this was a single process Image?

You say "The image must contain support for the class builder to be able to
be bootstrapped."
When you create the SmalltalkImage>>run method in the guest environment, is
that actually *running* to compiled as normal using its class builder?

How difficult would it be for the guest image to invoke class builder via
seamless in the host image?
And how much smaller could the image get if the class builder was removed.

It could be cool if this bootstrap creation process was integrated in
PharoLauncher as a GUI tool.  Then later the ability to download these
mini-image to an embedded controller could be added.

cheers -ben

P.S. Could you maybe blog this also, to make it easier to replicate and
copy-paste the Playground text.

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso


This is what we call having a vision :)




Nice!

It is interesting how all these projects are coming together… :-)

Marcus

On 24 Feb 2017, at 13:36, Pavel Krivanek   
wrote:


Hi,

I have published a short video of the Pharo bootstrapping from a Ring  
model that is browsed and modified by the Calypso browser.

https://www.youtube.com/watch?v=QguZSPKo7-w

No audio, please enable subtitles for the description.

Cheers,
-- Pavel






--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Pharo 60 : 60410 DNU on commit and no idea how to copy the stack :((((((((((((((((((((((((((((((((((((((((((((((


thanks
Yes it will be much better.

Stef

On Fri, 24 Feb 2017 10:39:51 +0100, Andrei Chis  
 wrote:





On Fri, Feb 24, 2017 at 8:44 AM, stepharong  wrote:
On Fri, 24 Feb 2017 00:05:10 +0100, Andrei Chis  
 wrote:



- How do we get the old textual stack description?


In the toolbar menu of the stack you find 'Fuel out stack' and 'Copy  
to clipboard'.
'Copy to clipboard' copies a textual description of the stack that can  
then be pasted in an email.
Is this the "old textual description" or are you referring to  
something else?


Ok this is what I was looking for.It looks like a generic copy past  
entry so I did not tried it.Can you rename it into  copy textual stack?


Indeed the name is confusing (even if it's always been like that).
I renamed it yesterday to 'Copy Stack to Clipboard'. Is that better? (It  
fits also with 'Fuel out Stack')


Cheers,
Andrei



Then I do not get why we could not get action about the current context  
and action about the complete stack together.Because these are not  
method that we see but contexts.
  
   Now I wanted to report it and share with you the stack. oh  
boy!
   I thought it was file out but no it just save one method  
definition (So great)


What action did you use to file our the textual description?


fileout in the main menu when you clik on the stack element.I never  
ever used it since 2006.



Cheers,

Andrei




   I got Fuelout the stack in the menu but this is not what I  
want. :(((


- Finally
   BTW I clicked on report and I have no idea what it does not  
mean. The fly by help is empty :(



do you have an idea about what is this Send a report: it looks totally  
obscure and useless.






So like an idiot I did a screen capture.
This broke totally my feel. In less than 10 min I left like either  
the system became less good or I'm totally stupid.


Stef






--Using Opera's mail client: http://www.opera.com/mail/






--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Raw pane on byteStrings

2017-02-24 15:43 GMT+01:00 Andrei Chis :

>
>
> On Fri, Feb 24, 2017 at 3:28 PM, Denis Kudriashov 
> wrote:
>
>>
>> 2017-02-24 14:29 GMT+01:00 Andrei Chis :
>>
>>> There should be no hidden costs in GTInspectorIndexedNodes.
>>> I made some experiments in the latest Pharo version and opening the Raw
>>> view on an array with one million numbers takes around 120ms when 100k
>>> elements are computed.
>>> I'll be curious how much it takes on your machine. To test update
>>> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
>>> and remove the annotation from Collection>>#gtInspectorItemsIn: (so
>>> that the Items presentation is not loaded)
>>>
>>> arrayLarge := (1 to: 100) asArray.
>>>
>>
>> I really wondering why anybody want instantiate wrapper objects for all
>> array items? Fast table approach is to not do that. Only visible part of
>> items should be recreated
>>
>
> This is how the inspector works for the Items view for Array objects. It
> also does not use any wrappers and only computes visible part.
>
>
As I said, it brings in a lazy data source adapted to arrays in a case
where it may well be not needed. My experiments show that there is no need
for this optimisation, at least for arrays ~ 100k.

Thierry

[Pharo-dev] Pharo days 2017 at Lille: block the dates 18/19 of May


Dear Pharoers

I’m happy to tell you that we will organise a new edition of the PharoDays  
at Lille the 18 et 19 of May.


The program and registration will be announced soon.
The setup will be similar to the ones of previous editions: Little cool  
presentations and hacking/discussions sessions

and a great social event.

https://medium.com/concerning-pharo/pharo-days-2016-c52fe4d7caf#.mqurj6rvi

So reserve the dates.

S.

PS: for students, we got some sponsoring from inria and cristal and if you  
need support let us know.

Re: [Pharo-dev] Raw pane on byteStrings

2017-02-24 15:28 GMT+01:00 Denis Kudriashov :

>
> 2017-02-24 14:29 GMT+01:00 Andrei Chis :
>
>> There should be no hidden costs in GTInspectorIndexedNodes.
>> I made some experiments in the latest Pharo version and opening the Raw
>> view on an array with one million numbers takes around 120ms when 100k
>> elements are computed.
>> I'll be curious how much it takes on your machine. To test update
>> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
>> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that
>> the Items presentation is not loaded)
>>
>> arrayLarge := (1 to: 100) asArray.
>>
>
> I really wondering why anybody want instantiate wrapper objects for all
> array items? Fast table approach is to not do that. Only visible part of
> items should be recreated
>

If you want. The fasttable code does the first thing of not creating a
wrapper interactive representation for all elements (i.e. a Morph). Then
the datasources may also be lazy: only wrap the objects for which a
representation is asked. The thing is that to be able to plan that in
totally generic UIs like an inspector, is that you need to create
placeholders (one way or another) to let the UI knows what kind and how
many elements the datasource holds... if the cost is low enough, just
creating a placeholder for each element may turn out to be just fine.

And the truth is, in local memory, creating a placeholder for every element
in a 100k collection costs about 0.

Remote can be handled either by a lazy source, or just by blindly creating
placeholders and caching the accesses to the real remote objects (with the
fact that you can expect that remote requests are only done when displaying
the element, not when building the widget). Simple, easy, fast enough, and
maybe better than considering than a lazy source on a remote source is a
ad-hoc implementation of a cache.

Regards,

Thierry

Re: [Pharo-dev] Raw pane on byteStrings

On Fri, Feb 24, 2017 at 3:28 PM, Denis Kudriashov 
wrote:

>
> 2017-02-24 14:29 GMT+01:00 Andrei Chis :
>
>> There should be no hidden costs in GTInspectorIndexedNodes.
>> I made some experiments in the latest Pharo version and opening the Raw
>> view on an array with one million numbers takes around 120ms when 100k
>> elements are computed.
>> I'll be curious how much it takes on your machine. To test update
>> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
>> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that
>> the Items presentation is not loaded)
>>
>> arrayLarge := (1 to: 100) asArray.
>>
>
> I really wondering why anybody want instantiate wrapper objects for all
> array items? Fast table approach is to not do that. Only visible part of
> items should be recreated
>

This is how the inspector works for the Items view for Array objects. It
also does not use any wrappers and only computes visible part.

Re: [Pharo-dev] Raw pane on byteStrings

2017-02-24 14:29 GMT+01:00 Andrei Chis :

> There should be no hidden costs in GTInspectorIndexedNodes.
> I made some experiments in the latest Pharo version and opening the Raw
> view on an array with one million numbers takes around 120ms when 100k
> elements are computed.
> I'll be curious how much it takes on your machine. To test update
> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that
> the Items presentation is not loaded)
>
> arrayLarge := (1 to: 100) asArray.
>

I really wondering why anybody want instantiate wrapper objects for all
array items? Fast table approach is to not do that. Only visible part of
items should be recreated

Re: [Pharo-dev] Raw pane on byteStrings

2017-02-24 14:29 GMT+01:00 Andrei Chis :

>
>
> On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Hi Andrei,
>>
>> 2017-02-24 11:31 GMT+01:00 Andrei Chis :
>>
>>> Hi Thierry,
>>>
>>> Indeed that's the simplest option now that we are using fast table.
>>>
>>> Just now in the case of the Raw view an OrderedCollection is used to
>>> store all displayed elements.
>>> If you display large collections every time you open the Raw view it
>>> will instantiate a collection of size 100k and instantiate 100k objects
>>> of type GTInspectorIndexedNode. With FastTable we can lazily load elements
>>> so we should be able to remove this behaviour and the limit. Just we need
>>> to make sure it will play nicely with automatic refresh. There is also the
>>> issue that when expanding an element in the tree if it's a collection you
>>> don't want to expand all elements.
>>>
>>
>> I'm not sure you need to worry too much about that one; in practical
>> experiments, creating that 100k collection for viewing (and the associated
>> nodes instances) isn't too costly (unless creating the
>> GTInspectorIndexedNodes has hidden costs: I've only experimented with the
>> EyeInspector framework).
>>
>
> There should be no hidden costs in GTInspectorIndexedNodes.
> I made some experiments in the latest Pharo version and opening the Raw
> view on an array with one million numbers takes around 120ms when 100k
> elements are computed.
> I'll be curious how much it takes on your machine. To test update
> indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn:
> and remove the annotation from Collection>>#gtInspectorItemsIn: (so that
> the Items presentation is not loaded)
>
> arrayLarge := (1 to: 100) asArray.
> arrayLarge inspect.
>

This is the values I get on my work laptop (core i3-2350M 2.30 Ghz); both
inspectors displays 100k elements.

(1 to: 100) asArray in: [ :s |  [s inspect] timeToRun] 0:00:00:00.064
(1 to: 100) asArray in: [:s | [GTInspector inspect: s] timeToRun]
0:00:00:00.381

Pharo 6 60411


>
>
>>
>> Opening the tree with all elements works fine in my experiments. Tuning
>> scrolling as done in Bloc is necessary, however.
>>
>>
>>>
>>> I'm looking now on a lazy data source for FastTable that plays nicely
>>> with GTInspector. Let's see how it will go. Help is always welcomed :)
>>>
>>
>> As I said: do not overoptimize that part... just remove that limitation
>> on the raw view and measure.
>>
>
> If I measure the Items view on the previous array it takes around 35ms.
> What I'd like to have is the same opening time for the Items view on large
> Sets and Dictionaries.
>

On my machine, the experiment is that displaying the set is fast, but the
system becomes totally unresponsive... which may be an issue with the self
refresh of the inspector. Yes, it was the culprit.

(1 to: 100) asSet in: [ :s |  [s inspect] timeToRun] 0:00:00:00.034
(1 to: 100) asSet in: [:s | [GTInspector inspect: s] timeToRun]
0:00:00:00.199

Regards,

Thierry


>
>
>>
>>
>>>
>>> I think I used the word paginator in the wrong way. If you have a very
>>> large collection (millions of elements) I do not want to scroll through
>>> elements but most likely jump to a certain element or view just a subset of
>>> all elements. Not really add a paginator like in web pages.
>>>
>>
>> Ok, millions of elements is a bit out of my scope... I'll look for
>> filtering then.
>>
>
> Yes, definitely filtering is the way to go there :)
>
> Cheers,
> Andrei
>
>
>>
>> Regards,
>>
>> Thierry
>>
>>
>>>
>>> Cheers,
>>> Andrei
>>>
>>> On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier <
>>> thierry.goub...@gmail.com> wrote:
>>>
 Hi Andrei,

 if you're using fasttable for the Raw view, you should be able to reach
 one 100k elements without issues. I did some experiments and it handles the
 load very well.

 Avoid the paginator at any cost. This thing is really user-unfriendly.

 Regards,

 Thierry

 2017-02-23 20:19 GMT+01:00 Andrei Chis :

> Hi Stef,
>
> Currently that's the default behaviour of the Raw view: it displays
> for collections only the first and the last 21 elements. The Items view
> however always should display all the elements of a collection.
>
> The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6
> now the speed of the Raw view is greately improved so we could increase
> those limits. Still for now there should still be some limit for the Raw
> view. Ideally we should add a small widget, something like a paginator, 
> for
> navigating through large and very large collections.
>
> Cheers,
> Andrei
>
> On Feb 23, 2017 19:35, "stepharong"  wrote:
>
>> Hi
>>
>> I'm trying to debug citezen generation and I have to compare strings.
>> Now I think that the raw views (in Pharo 50) is not good because we
>> cannot see all the items i

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

2017-02-24 Thread Esteban A. Maringolo

If anybody ever did an `apt-cache search name` it will be clear that
having a good, concise, intention revealing package name is better
than having a sophisticated one. I don't see how in Pharo catalogs and
other discovery/browsing mechanisms it would be different.

Best regards!

Esteban A. Maringolo


2017-02-24 7:34 GMT-03:00 Markus Fritsche :
> Hello,
>
> I guess the vote is already cast, but I'd like to add my two Cents:
>
> the packages now have a description that give an idea about what the package
> is supposed to do. Still, discoverability should be considered when finding
> a name. That's why I would prefer something like TelePharo, since the name
> already hints at the core functionality.
>
> Best regards,
>   Markus
>
>
> Am 29.01.2017 15:14, schrieb stepharong:
>>
>> Hi guys
>>
>> Since we will push the remote tools (videos/web...) I would like to
>> get  some ideas for a cool name.
>> Any ideas?
>>
>> Because Pharmide (looks like medicine or chemical product).
>> Since I vaguely remember some german Pharmide made me think about
>> Fern(sehen) but this is not a good name.
>>
>> Stef
>>
>>
>> --
>
>

Re: [Pharo-dev] Raw pane on byteStrings

On Fri, Feb 24, 2017 at 12:16 PM, Thierry Goubier  wrote:

> Hi Andrei,
>
> 2017-02-24 11:31 GMT+01:00 Andrei Chis :
>
>> Hi Thierry,
>>
>> Indeed that's the simplest option now that we are using fast table.
>>
>> Just now in the case of the Raw view an OrderedCollection is used to
>> store all displayed elements.
>> If you display large collections every time you open the Raw view it will
>> instantiate a collection of size 100k and instantiate 100k objects of
>> type GTInspectorIndexedNode. With FastTable we can lazily load elements so
>> we should be able to remove this behaviour and the limit. Just we need to
>> make sure it will play nicely with automatic refresh. There is also the
>> issue that when expanding an element in the tree if it's a collection you
>> don't want to expand all elements.
>>
>
> I'm not sure you need to worry too much about that one; in practical
> experiments, creating that 100k collection for viewing (and the associated
> nodes instances) isn't too costly (unless creating the
> GTInspectorIndexedNodes has hidden costs: I've only experimented with the
> EyeInspector framework).
>

There should be no hidden costs in GTInspectorIndexedNodes.
I made some experiments in the latest Pharo version and opening the Raw
view on an array with one million numbers takes around 120ms when 100k
elements are computed.
I'll be curious how much it takes on your machine. To test update
indexableDisplayLimit to 5 in Object>>#gtInspectorVariableNodesIn: and
remove the annotation from Collection>>#gtInspectorItemsIn: (so that the
Items presentation is not loaded)

arrayLarge := (1 to: 100) asArray.
arrayLarge inspect.


>
> Opening the tree with all elements works fine in my experiments. Tuning
> scrolling as done in Bloc is necessary, however.
>
>
>>
>> I'm looking now on a lazy data source for FastTable that plays nicely
>> with GTInspector. Let's see how it will go. Help is always welcomed :)
>>
>
> As I said: do not overoptimize that part... just remove that limitation on
> the raw view and measure.
>

If I measure the Items view on the previous array it takes around 35ms.
What I'd like to have is the same opening time for the Items view on large
Sets and Dictionaries.


>
>
>>
>> I think I used the word paginator in the wrong way. If you have a very
>> large collection (millions of elements) I do not want to scroll through
>> elements but most likely jump to a certain element or view just a subset of
>> all elements. Not really add a paginator like in web pages.
>>
>
> Ok, millions of elements is a bit out of my scope... I'll look for
> filtering then.
>

Yes, definitely filtering is the way to go there :)

Cheers,
Andrei


>
> Regards,
>
> Thierry
>
>
>>
>> Cheers,
>> Andrei
>>
>> On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> Hi Andrei,
>>>
>>> if you're using fasttable for the Raw view, you should be able to reach
>>> one 100k elements without issues. I did some experiments and it handles the
>>> load very well.
>>>
>>> Avoid the paginator at any cost. This thing is really user-unfriendly.
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>> 2017-02-23 20:19 GMT+01:00 Andrei Chis :
>>>
 Hi Stef,

 Currently that's the default behaviour of the Raw view: it displays for
 collections only the first and the last 21 elements. The Items view however
 always should display all the elements of a collection.

 The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6
 now the speed of the Raw view is greately improved so we could increase
 those limits. Still for now there should still be some limit for the Raw
 view. Ideally we should add a small widget, something like a paginator, for
 navigating through large and very large collections.

 Cheers,
 Andrei

 On Feb 23, 2017 19:35, "stepharong"  wrote:

> Hi
>
> I'm trying to debug citezen generation and I have to compare strings.
> Now I think that the raw views (in Pharo 50) is not good because we
> cannot see all the items in raw format.
> See the attachements. It jumps from 21 to 174 ...
> and what I want to see is of course in the middle.
>
> Is it me or there is something wrong there.
> Stef


>>>
>>
>

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 13:53 GMT+01:00 Cyril Ferlicot D. :

> On 24/02/2017 13:36, Pavel Krivanek wrote:
> > Hi,
> >
> > I have published a short video of the Pharo bootstrapping from a Ring
> > model that is browsed and modified by the Calypso browser.
> >
> > https://www.youtube.com/watch?v=QguZSPKo7-w
> >
> > No audio, please enable subtitles for the description.
> >
> > Cheers,
> > -- Pavel
>
> Hi!
>
> Can you explain a little what is Ring model for those who don't know as
> me? :D
>
>
Ring is a Smalltalk metamodel implementation. It's simply a set of classes
that statically describe elements in the Smalltalk system, like classes,
methods, instance variables etc. Ring was included into the image in Pharo
1.4.

Currently we have several similar metamodels in the image or as external
projects. Monticello definitions, RBBrowserEnvironment, Ring, Ficus. We are
working on the new Ring implementation that tries to solve problems of the
original one and enables things like:

- browse packages without need of loading them
- analyse them (QA checks, ...)
- bootstrap from an environment model
- work on remote images
- join and analyze several models as one (like image model+external package
model)
- work with incomplete models
etc.

In ideal state the metamodel should be a layer on top of the environment
which all tools use and thus you can use the same workflow for various code
sources. Like be able to modify and explore an external package with the
standard Pharo tools without need of installation of it.

Cheers,
-- Pavel

> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 Thread Cyril Ferlicot D.

On 24/02/2017 13:36, Pavel Krivanek wrote:
> Hi,
> 
> I have published a short video of the Pharo bootstrapping from a Ring
> model that is browsed and modified by the Calypso browser. 
> 
> https://www.youtube.com/watch?v=QguZSPKo7-w
> 
> No audio, please enable subtitles for the description.
> 
> Cheers,
> -- Pavel

Hi!

Can you explain a little what is Ring model for those who don't know as
me? :D

-- 
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso

2017-02-24 Thread denker

Nice!

It is interesting how all these projects are coming together… :-)

Marcus

> On 24 Feb 2017, at 13:36, Pavel Krivanek  wrote:
> 
> Hi,
> 
> I have published a short video of the Pharo bootstrapping from a Ring model 
> that is browsed and modified by the Calypso browser. 
> 
> https://www.youtube.com/watch?v=QguZSPKo7-w 
> 
> 
> No audio, please enable subtitles for the description.
> 
> Cheers,
> -- Pavel

[Pharo-dev] Pharo bootstrap with Ring and Calypso

Hi,

I have published a short video of the Pharo bootstrapping from a Ring model
that is browsed and modified by the Calypso browser.

https://www.youtube.com/watch?v=QguZSPKo7-w

No audio, please enable subtitles for the description.

Cheers,
-- Pavel

[Pharo-dev] [Pharo6][Issue Tracker] 80 Issues tagged for Pharo6

2017-02-24 Thread Marcus Denker

Hi,

We have 80 issues left that have the Milestone tag for Pharo6.

https://pharo.fogbugz.com/f/filters/1192/6-0-All

It would really be nice if people could check all the issues and decide:

“Is this a release critical issue?”

if yes —> increase priory to at least “Must Fix”. If not, consider removing the
Milestone tag and put it to “Later”.

At the sprint next week we will automatically remove all Milestone-6 tags
from all issues that are “Would be nice” or lower.

Marcus

Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

2017-02-24 Thread Peter Uhnak

Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something 
broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> > 
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
> 
> I've downloaded the latest VM and it works as expected. Thanks!
> 
> Peter

Re: [Pharo-dev] Raw pane on byteStrings

Hi Andrei,

2017-02-24 11:31 GMT+01:00 Andrei Chis :

> Hi Thierry,
>
> Indeed that's the simplest option now that we are using fast table.
>
> Just now in the case of the Raw view an OrderedCollection is used to store
> all displayed elements.
> If you display large collections every time you open the Raw view it will
> instantiate a collection of size 100k and instantiate 100k objects of
> type GTInspectorIndexedNode. With FastTable we can lazily load elements so
> we should be able to remove this behaviour and the limit. Just we need to
> make sure it will play nicely with automatic refresh. There is also the
> issue that when expanding an element in the tree if it's a collection you
> don't want to expand all elements.
>

I'm not sure you need to worry too much about that one; in practical
experiments, creating that 100k collection for viewing (and the associated
nodes instances) isn't too costly (unless creating the
GTInspectorIndexedNodes has hidden costs: I've only experimented with the
EyeInspector framework).

Opening the tree with all elements works fine in my experiments. Tuning
scrolling as done in Bloc is necessary, however.


>
> I'm looking now on a lazy data source for FastTable that plays nicely with
> GTInspector. Let's see how it will go. Help is always welcomed :)
>

As I said: do not overoptimize that part... just remove that limitation on
the raw view and measure.


>
> I think I used the word paginator in the wrong way. If you have a very
> large collection (millions of elements) I do not want to scroll through
> elements but most likely jump to a certain element or view just a subset of
> all elements. Not really add a paginator like in web pages.
>

Ok, millions of elements is a bit out of my scope... I'll look for
filtering then.

Regards,

Thierry


>
> Cheers,
> Andrei
>
> On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Hi Andrei,
>>
>> if you're using fasttable for the Raw view, you should be able to reach
>> one 100k elements without issues. I did some experiments and it handles the
>> load very well.
>>
>> Avoid the paginator at any cost. This thing is really user-unfriendly.
>>
>> Regards,
>>
>> Thierry
>>
>> 2017-02-23 20:19 GMT+01:00 Andrei Chis :
>>
>>> Hi Stef,
>>>
>>> Currently that's the default behaviour of the Raw view: it displays for
>>> collections only the first and the last 21 elements. The Items view however
>>> always should display all the elements of a collection.
>>>
>>> The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6
>>> now the speed of the Raw view is greately improved so we could increase
>>> those limits. Still for now there should still be some limit for the Raw
>>> view. Ideally we should add a small widget, something like a paginator, for
>>> navigating through large and very large collections.
>>>
>>> Cheers,
>>> Andrei
>>>
>>> On Feb 23, 2017 19:35, "stepharong"  wrote:
>>>
 Hi

 I'm trying to debug citezen generation and I have to compare strings.
 Now I think that the raw views (in Pharo 50) is not good because we
 cannot see all the items in raw format.
 See the attachements. It jumps from 21 to 174 ...
 and what I want to see is of course in the middle.

 Is it me or there is something wrong there.
 Stef
>>>
>>>
>>
>

Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?

2017-02-24 Thread Markus Fritsche


Hello,

I guess the vote is already cast, but I'd like to add my two Cents:

the packages now have a description that give an idea about what the 
package is supposed to do. Still, discoverability should be considered 
when finding a name. That's why I would prefer something like TelePharo, 
since the name already hints at the core functionality.


Best regards,
  Markus

Am 29.01.2017 15:14, schrieb stepharong:

Hi guys

Since we will push the remote tools (videos/web...) I would like to
get  some ideas for a cool name.
Any ideas?

Because Pharmide (looks like medicine or chemical product).
Since I vaguely remember some german Pharmide made me think about
Fern(sehen) but this is not a good name.

Stef


--

Re: [Pharo-dev] Raw pane on byteStrings

Hi Thierry,

Indeed that's the simplest option now that we are using fast table.

Just now in the case of the Raw view an OrderedCollection is used to store
all displayed elements.
If you display large collections every time you open the Raw view it will
instantiate a collection of size 100k and instantiate 100k objects of
type GTInspectorIndexedNode. With FastTable we can lazily load elements so
we should be able to remove this behaviour and the limit. Just we need to
make sure it will play nicely with automatic refresh. There is also the
issue that when expanding an element in the tree if it's a collection you
don't want to expand all elements.

I'm looking now on a lazy data source for FastTable that plays nicely with
GTInspector. Let's see how it will go. Help is always welcomed :)

I think I used the word paginator in the wrong way. If you have a very
large collection (millions of elements) I do not want to scroll through
elements but most likely jump to a certain element or view just a subset of
all elements. Not really add a paginator like in web pages.

Cheers,
Andrei

On Fri, Feb 24, 2017 at 10:37 AM, Thierry Goubier  wrote:

> Hi Andrei,
>
> if you're using fasttable for the Raw view, you should be able to reach
> one 100k elements without issues. I did some experiments and it handles the
> load very well.
>
> Avoid the paginator at any cost. This thing is really user-unfriendly.
>
> Regards,
>
> Thierry
>
> 2017-02-23 20:19 GMT+01:00 Andrei Chis :
>
>> Hi Stef,
>>
>> Currently that's the default behaviour of the Raw view: it displays for
>> collections only the first and the last 21 elements. The Items view however
>> always should display all the elements of a collection.
>>
>> The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6
>> now the speed of the Raw view is greately improved so we could increase
>> those limits. Still for now there should still be some limit for the Raw
>> view. Ideally we should add a small widget, something like a paginator, for
>> navigating through large and very large collections.
>>
>> Cheers,
>> Andrei
>>
>> On Feb 23, 2017 19:35, "stepharong"  wrote:
>>
>>> Hi
>>>
>>> I'm trying to debug citezen generation and I have to compare strings.
>>> Now I think that the raw views (in Pharo 50) is not good because we
>>> cannot see all the items in raw format.
>>> See the attachements. It jumps from 21 to 174 ...
>>> and what I want to see is of course in the middle.
>>>
>>> Is it me or there is something wrong there.
>>> Stef
>>
>>
>

Re: [Pharo-dev] [ANN] Woden 2 first release for OS X and Linux

2017-02-24 Thread nolwenn

Wonderful ! I will try it soon.

Thanks !

Nolwenn



--
View this message in context: 
http://forum.world.st/ANN-Woden-2-first-release-for-OS-X-and-Linux-tp4935693p4935742.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Pharo 60 : 60410 DNU on commit and no idea how to copy the stack :((((((((((((((((((((((((((((((((((((((((((((((

On Fri, Feb 24, 2017 at 8:44 AM, stepharong  wrote:

> On Fri, 24 Feb 2017 00:05:10 +0100, Andrei Chis <
> chisvasileand...@gmail.com> wrote:
>
>
>>
>> - How do we get the old textual stack description?
>>
>
> In the toolbar menu of the stack you find 'Fuel out stack' and 'Copy to
> clipboard'.
> 'Copy to clipboard' copies a textual description of the stack that can
> then be pasted in an email.
> Is this the "old textual description" or are you referring to something
> else?
>
>
> Ok this is what I was looking for.
> It looks like a generic copy past entry so I did not tried it.
> Can you rename it into  copy textual stack?
>

Indeed the name is confusing (even if it's always been like that).
I renamed it yesterday to 'Copy Stack to Clipboard'. Is that better? (It
fits also with 'Fuel out Stack')

Cheers,
Andrei


>
> Then I do not get why we could not get action about the current context
> and action about the complete stack together.
> Because these are not method that we see but contexts.
>
>
>
>
>> Now I wanted to report it and share with you the stack. oh
>> boy!
>> I thought it was file out but no it just save one method
>> definition (So great)
>>
>
> What action did you use to file our the textual description?
>
>
> fileout in the main menu when you clik on the stack element.
> I never ever used it since 2006.
>
>
> Cheers,
> Andrei
>
>
>
>>
>> I got Fuelout the stack in the menu but this is not what I want.
>> :(((
>
>
>> - Finally
>> BTW I clicked on report and I have no idea what it does not mean.
>> The fly by help is empty :(
>
>
>
> do you have an idea about what is this Send a report: it looks totally
> obscure and useless.
>
>
>>
>>
>> So like an idiot I did a screen capture.
>> This broke totally my feel. In less than 10 min I left like either the
>> system became less good or I'm totally stupid.
>>
>> Stef
>
>
>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>

Re: [Pharo-dev] Raw pane on byteStrings

2017-02-24 10:37 GMT+01:00 Thierry Goubier :

> Hi Andrei,
>
> if you're using fasttable for the Raw view, you should be able to reach
> one 100k elements without issues. I did some experiments and it handles the
> load very well.
>
> Avoid the paginator at any cost. This thing is really user-unfriendly.
>

+100

Re: [Pharo-dev] Raw pane on byteStrings

Hi Andrei,

if you're using fasttable for the Raw view, you should be able to reach one
100k elements without issues. I did some experiments and it handles the
load very well.

Avoid the paginator at any cost. This thing is really user-unfriendly.

Regards,

Thierry

2017-02-23 20:19 GMT+01:00 Andrei Chis :

> Hi Stef,
>
> Currently that's the default behaviour of the Raw view: it displays for
> collections only the first and the last 21 elements. The Items view however
> always should display all the elements of a collection.
>
> The main problem with the Raw view in Pharo 5 is the speed. In Pharo 6 now
> the speed of the Raw view is greately improved so we could increase those
> limits. Still for now there should still be some limit for the Raw view.
> Ideally we should add a small widget, something like a paginator, for
> navigating through large and very large collections.
>
> Cheers,
> Andrei
>
> On Feb 23, 2017 19:35, "stepharong"  wrote:
>
>> Hi
>>
>> I'm trying to debug citezen generation and I have to compare strings.
>> Now I think that the raw views (in Pharo 50) is not good because we
>> cannot see all the items in raw format.
>> See the attachements. It jumps from 21 to 174 ...
>> and what I want to see is of course in the middle.
>>
>> Is it me or there is something wrong there.
>> Stef
>
>

Re: [Pharo-dev] Raw pane on byteStrings