[Pharo-dev] Layout in bloc

[Alexandre Bergel]

Hi!

I am working on a popup support in Bloc and I am facing a problem. Consider the 
following code:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
space := BlSpace new.
space root layout: BlLinearLayout horizontal.
10
timesRepeat: [ | e |
e := (BlRectangle new extent: 20 @ 20) asElement.
e background: Color random.
space root addChild: e ].
space root children withIndexDo: [ :e :index | e translateBy: (index * 
30) @ 10 ].

space root children do: [ :e | 
e
addEventHandler:
(BlEventHandler
on: BlMouseEnterEvent
do: [ :evt | 
| txt |
txt := BlText new
position: evt position;
fill: Color red;
text: 'Hello World'.

e parent addChild: txt ]).

 ].
space show
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

If you uncomment the second line (“space root layout:…”), then the string hello 
world is added text to the element in which the mouse enter. With the layout, 
the string is added at the end of the line.

I like very much the idea of having the layout applied when elements are added 
(even I suspect we may have scalability issues very soon), but in that 
situation, this is not wished.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] About Pharo 60

[Cyril Ferlicot D.]

Le 27/08/2016 à 14:32, Esteban Lorenzano a écrit :
> yes, some years ago I made a package for this. 
> later Ben tried something similar with the user manager.
> none of those approaches worked as general approach because you need to 
> “close” a lot of things…  (not just the spotter… which by the way, NEEDS to 
> have a setting, no idea who answered you that but he is wrong), and image is 
> not prepared for that.
> 

I checked the issue tracker and it was closed because people though that
we need a better way to disable shortcuts in general and that it is not
specific to Spotter.

https://pharo.fogbugz.com/f/cases/17041/We-should-be-able-to-disable-GTSpotter

But we still cannot disable/enable Spotter without hacking into KM :(
I think that sometimes it is good to think about a generic solution, but
we still can get a temporary one because everyone cannot wait 3 years
that the good one works. We can still let a flag "Remove this temporary
solution after we finish ".


> of course is still possible :)
> 
> anyway, today I would tackle a solution in a different way: I would open my 
> app morph on an SDL2 window and not touch the word at all (opening a headless 
> image). This is not possible in windows because when you do “headless” it 
> just laugh at you, but is doable in the not-so-long term.
> 
> Esteban
> 

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] About Pharo 60

[Cyril Ferlicot D.]

Le 27/08/2016 à 14:39, stepharo a écrit :
> Cyril what would be good is to share what you are disabling and to tunr
> such points into points that can be turned
> but inside Pharo like that you push the logic to the system.
> 

Since we moved to a Seaside application not so long after I joined
Synectique we only disable some basic things.

If I don't say anything wrong here is what we did:
- Remove repositories containing "Synectique" in the name
- Reset all passwords (MCHttpRepository clearPasswords)
- Install a custom world menu (WorldState desktopMenuPragmaKeyword: 'XXX')
- Remove Halos (At the time I created an issue to be able to do `Morph
halosEnabled: false`, but it would be useful to make that a setting)
- Remove Spotter ((KMRepository default globalCategories detect: [ :each
| each isKindOf: GTSpotterGlobalShortcut ]) allEntries keymaps do:
#disable)
- Usman also added a transparent Morph that could catch some shortcuts I
think and that would block some actions. We could disabled it with a
dialog and a password.

> Now this is important to see that if people for which the value is high
> do not work on something
> why others would do it.

>> When I improved the deployment of Synectique Tools I asked to get a
>> simple way to disable Spotter via a setting but I got as answer "No
>> because you can do it by removing a global shortcut so it is not
>> needed.".
> 
> I do not know how to do it either. So we should document that.

What I did:

(KMRepository default globalCategories detect: [ :each | each isKindOf:
GTSpotterGlobalShortcut ]) allEntries keymaps do: #disable

Ugly I know but it worked and was only called once in the CI.

>> People in companies don't have the time to learn how shortcuts work and
>> how to remove one without impacting something else. And they don't have
>> the time to check Spotter code to know how it is call.
>>
>> If the image is able to have a deployment mode then I don't care how
>> Spotter is disabled (setting or removing a shortcut). But for now we
>> don't have it. :)
> No you should care because one day you will come with a new requirement :)
> I understand what you mean but the point is that Pharo is our common
> architecture
> so we should just all pay attention and we cannot ask people to do
> everything because
> we all have 24 h a day. So we should be smart, share and build together.
>

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] About better communication in the community

[Denis Kudriashov]

In context of discussion how to propose Mocketry and StateSpecs to be part
of Pharo?
We often said that Pharo provides the best approach to TDD but we have no
mock library inside. And nobody use mocks for Pharo tests because of that

2016-08-24 6:51 GMT+02:00 stepharo :

> Hi guys
>
> the board got a good discussion at ESUG about how to improve and a lot of
> the discussion turned around improving communication. We got some ideas
> that we will propose soon but I would like to get *your* ideas.
>
> If you have idea about improving communication around pharo please tell us.
>
>
> Stef
>
>
>

Re: [Pharo-dev] About better communication in the community

[Denis Kudriashov]

2016-08-24 9:38 GMT+02:00 stepharo :

> Igor looked at Twisty seriously and I do not think that it could handle
> large cobol files.
>
> (you see funnily denis is doing the same with Seamless - He rewrote it
> from scratch while
> nick worked on it for several years).
>

Just to clarify:
Twisty was not rewrite of TxText. When Igor returned to project I already
moved to my design ideas which was opposite to Igor. And I just decided to
finish what I started with new project name.
About long files - TxText optimization needs to be implemented in Twisty.
That's all. Current design could be evolved for it.
I does not know which project is better. In Twisty I implemented my
practical needs: various kinds of editors. To approve which design is
better someone needs to implement same in TxText and compare it with
Twisty. Probably simple example of masked text could be enough.

And I must mention Seamless to clarify that Nick work is not lost. He
implemented important ideas on asynchronous data transfer which helps me a
lot. I extracted them to separate project Basys with better abstraction
which is independent from Seamless goals. It improved testability and
leaded to rest of other changes.

Re: [Pharo-dev] About better communication in the community

[Denis Kudriashov]

Hi

2016-08-24 18:58 GMT+02:00 Hernán Morales Durand :

> 2. Features that goes inside Pharo are not decided by vote. They have to
>> add value and share the Pharo vision (pointed in the vision document who is
>> not slightly updated but still guides our steps). We try to reach consensus
>> and if it is not possible, then we decide. Yes, is like that… I’m sorry for
>> not being perfect democratic but this was never the idea of Pharo (it *has*
>> a benevolent dictator… who by the way is not me but a group, the board).
>>
>>
> Ok, now people can see one reason why Pharo is light years from the
> popularity of other OSS. I don't get how do you expect success with Pharo
> if you never change your mindset... I read a lot of papers and see KDE,
> gcc, Linux, NetBeans, Python, Mozilla, Apache collaboration models... never
> *ever* read something like that, specially now where OSS literature is
> considering distributed democracy.
>

I would say Pharo is still too young. And Pharo parents want to bring up it
in own way.
I think at some point Pharo could become adult enough to move away from
parents (in good meaning of these words:) (without losing respect to
parents vision)).

Re: [Pharo-dev] MorphicDoc?

[Dimitris Chloupis]

Yeah my bad it would suppose to be a documentation project for Morphic.
There should be some content though. But since we move to Bloc I will
delete it.
On Sat, 27 Aug 2016 at 12:11, Nicolai Hess  wrote:

> Anyone knows what is MorphicDoc (Kilon?)
> I loaded the stable configuration in Pharo 5.0, but I can not find any
> content.
>
> (missing dependencies / packagese maybe ? )
>

Re: [Pharo-dev] About better communication in the community

[stepharo]

Hi yuriy

A package manifest is the place where we keep package rules and meta data.

We should add documentation and others.

I think that all the packages should have a XXXManifest.

There we can define a method preUnload and after we can define  a class 
PackageUnloader (or put the logic in the PackageOrganiser way better :)).


So that we can say

PackageOrganiser current unload: 'XXX' and the preUnload is executed.


Stef


Le 27/8/16 à 16:23, Yuriy Tymchuk a écrit :

On 27 Aug 2016, at 11:00, stepharo  wrote:

You see hernan doing positively is the best way to make that things happen

We can have a

preUnload hook

Now we should check how it fits with cleanForProduction and others.

But we should definitively have a way to express this.

So let us see how we can design it and then just implement it. I'm sure that GT 
people are open to such hooks

and if you really want to get a better Pharo for you then talk to them and us.


https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA

I like the idea, but how should it work? What is the package manifest? And how 
the unload protocol looks like? Do I only add a method called #unload to 
somewhere?

Uko


https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-SpecDebugger

https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-GT-Debugger

https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT

Stef

Re: [Pharo-dev] About better communication in the community

[Yuriy Tymchuk]

> On 27 Aug 2016, at 11:00, stepharo  wrote:
> 
> You see hernan doing positively is the best way to make that things happen
> 
> We can have a
> 
>preUnload hook
> 
> Now we should check how it fits with cleanForProduction and others.
> 
> But we should definitively have a way to express this.
> 
> So let us see how we can design it and then just implement it. I'm sure that 
> GT people are open to such hooks
> 
> and if you really want to get a better Pharo for you then talk to them and us.
> 
> 
> https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA

I like the idea, but how should it work? What is the package manifest? And how 
the unload protocol looks like? Do I only add a method called #unload to 
somewhere?

Uko

> 
> https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-SpecDebugger
> 
> https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-GT-Debugger
> 
> https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT
> 
> Stef
> 

[Pharo-dev] Confused by remote logic ;)

[stepharo]

KomitNewSlice>>remote

^ MCRepositoryGroup default repositories
detect: [ :e | e description = 
'http://smalltalkhub.com/mc/Pharo/Pharo50Inbox/main/' ]
ifNone: [ MCRepositoryGroup default repositories detect: [ :e | 
e description = 'http://smalltalkhub.com/mc/Pharo/Pharo50Inbox/main' ] ]



may be the first time one is magically created :)


Stef

[Pharo-dev] Polymorphic results would be good

[stepharo]

Hi

I'm cleaning Smalltalk ui icons usage again and more :)

I just want to share with you. I see code like that

KomitDirectoryRemote>>icon
^ 'DIR'

KomitGemstoneRemote>> icon
^ Smalltalk ui icons iconNamed: #komitterGemstoneRemote

It would be nice if we could be cleaner and makes sure that we do not 
return totally different objects.


Stef

PS: Some of you can understand why I was not found of Komitter and 
suggested to remove it.


So let us improve it.

Re: [Pharo-dev] About Pharo 60

[Esteban Lorenzano]

> On 27 Aug 2016, at 14:40, stepharo  wrote:
> 
> Hi esteban
> 
> I think that we should identify the main hook points and slowly prepare them.
> 
> The system should be prepared for that so that we just need to pass a context 
> to configure it.

.. I should have that old package somewhere… it will not work, and it was not 
very subtle… but it has to be somewhere :)

Esteban 

> 
> Stef
> 
> 
> Le 27/8/16 à 14:32, Esteban Lorenzano a écrit :
>> yes, some years ago I made a package for this.
>> later Ben tried something similar with the user manager.
>> none of those approaches worked as general approach because you need to 
>> “close” a lot of things…  (not just the spotter… which by the way, NEEDS to 
>> have a setting, no idea who answered you that but he is wrong), and image is 
>> not prepared for that.
>> 
>> of course is still possible :)
>> 
>> anyway, today I would tackle a solution in a different way: I would open my 
>> app morph on an SDL2 window and not touch the word at all (opening a 
>> headless image). This is not possible in windows because when you do 
>> “headless” it just laugh at you, but is doable in the not-so-long term.
>> 
>> Esteban
>> 
>>> On 27 Aug 2016, at 13:39, Cyril Ferlicot D.  
>>> wrote:
>>> 
>>> Le 27/08/2016 à 13:18, stepharo a écrit :
 
 YES!!!
 
 Do you know how Settings works?
 We can adapt it this way.
>>> When I improved the deployment of Synectique Tools I asked to get a
>>> simple way to disable Spotter via a setting but I got as answer "No
>>> because you can do it by removing a global shortcut so it is not needed.".
>>> 
>>> People in companies don't have the time to learn how shortcuts work and
>>> how to remove one without impacting something else. And they don't have
>>> the time to check Spotter code to know how it is call.
>>> 
>>> If the image is able to have a deployment mode then I don't care how
>>> Spotter is disabled (setting or removing a shortcut). But for now we
>>> don't have it. :)
>>> 
 I mean the User approach that Benjmain proposed and was pushed in Pharo
 was not good because it was not modular. Now each part of the system
 should be
 defined in way that it can be set just as a setting.
 We should not have
 
 World
User current = ifTrue
 
 But
 
 World use: userSetting
 
 and World should handle it.
 There is way more to do :)
 When you deploy on linux you should be able to say beSilent to the
 system (do not write on places that you cannot).
 Valentin works on it and we should continue
 
 Stef
 
>>> The fact that there is much more to do is the main reason for Pharo to
>>> do it and not the developer. The developer cannot know all the system
>>> and will not be able to protect the code of his company well because he
>>> will forget something as to disable ctrl+o+p (or he is a god developer!
>>> But everyone is not).
>>> 
>>> This is a large thing to do, so it would be cool that everyone keep that
>>> in mind to allow it little by little (as with the work of Valentin).
>>> 
>>> -- 
>>> Cyril Ferlicot
>>> 
>>> http://www.synectique.eu
>>> 
>>> 165 Avenue Bretagne
>>> Lille 59000 France
>>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] About better communication in the community

[stepharo]

So I think that I will keep Eyeinspector for Spec because it works well 
using Spec.


I will package BasicInspector

Then we will see. I think that Smalltalk tools inspector is not good 
because it is yet another global


while the tools should have a tool context (but with a registration 
mechanism to get refreshed in case).



Stef


Le 27/8/16 à 10:51, stepharo a écrit :
I took the inspector from Pharo20 and I will check if it is working in 
Pharo.

Then I will
- check EyeInspector from a package perspective (extensions and 
the rest)

- make sure that we can remove EyeInspector
- package the attached file as BasicInspector.

Now if you want to help you are welcome.

Stef

Re: [Pharo-dev] About Pharo 60

[stepharo]

Hi esteban

I think that we should identify the main hook points and slowly prepare 
them.


The system should be prepared for that so that we just need to pass a 
context to configure it.


Stef


Le 27/8/16 à 14:32, Esteban Lorenzano a écrit :

yes, some years ago I made a package for this.
later Ben tried something similar with the user manager.
none of those approaches worked as general approach because you need to “close” 
a lot of things…  (not just the spotter… which by the way, NEEDS to have a 
setting, no idea who answered you that but he is wrong), and image is not 
prepared for that.

of course is still possible :)

anyway, today I would tackle a solution in a different way: I would open my app 
morph on an SDL2 window and not touch the word at all (opening a headless 
image). This is not possible in windows because when you do “headless” it just 
laugh at you, but is doable in the not-so-long term.

Esteban


On 27 Aug 2016, at 13:39, Cyril Ferlicot D.  wrote:

Le 27/08/2016 à 13:18, stepharo a écrit :


YES!!!

Do you know how Settings works?
We can adapt it this way.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not needed.".

People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)


I mean the User approach that Benjmain proposed and was pushed in Pharo
was not good because it was not modular. Now each part of the system
should be
defined in way that it can be set just as a setting.
We should not have

World
User current = ifTrue

But

World use: userSetting

and World should handle it.
There is way more to do :)
When you deploy on linux you should be able to say beSilent to the
system (do not write on places that you cannot).
Valentin works on it and we should continue

Stef


The fact that there is much more to do is the main reason for Pharo to
do it and not the developer. The developer cannot know all the system
and will not be able to protect the code of his company well because he
will forget something as to disable ctrl+o+p (or he is a god developer!
But everyone is not).

This is a large thing to do, so it would be cool that everyone keep that
in mind to allow it little by little (as with the work of Valentin).

--
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France

Re: [Pharo-dev] About Pharo 60

[stepharo]

Cyril what would be good is to share what you are disabling and to tunr 
such points into points that can be turned

but inside Pharo like that you push the logic to the system.

Now this is important to see that if people for which the value is high 
do not work on something

why others would do it.

YES!!!

Do you know how Settings works?
We can adapt it this way.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not needed.".


I do not know how to do it either. So we should document that.

People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)

No you should care because one day you will come with a new requirement :)
I understand what you mean but the point is that Pharo is our common 
architecture
so we should just all pay attention and we cannot ask people to do 
everything because

we all have 24 h a day. So we should be smart, share and build together.




I mean the User approach that Benjmain proposed and was pushed in Pharo
was not good because it was not modular. Now each part of the system
should be
defined in way that it can be set just as a setting.
We should not have

World
 User current = ifTrue

But

World use: userSetting

and World should handle it.
There is way more to do :)
When you deploy on linux you should be able to say beSilent to the
system (do not write on places that you cannot).
Valentin works on it and we should continue

Stef


The fact that there is much more to do is the main reason for Pharo to
do it and not the developer. The developer cannot know all the system
and will not be able to protect the code of his company well because he
will forget something as to disable ctrl+o+p (or he is a god developer!
But everyone is not).

This is a large thing to do, so it would be cool that everyone keep that
in mind to allow it little by little (as with the work of Valentin).

Re: [Pharo-dev] About Pharo 60

[Esteban Lorenzano]

yes, some years ago I made a package for this. 
later Ben tried something similar with the user manager.
none of those approaches worked as general approach because you need to “close” 
a lot of things…  (not just the spotter… which by the way, NEEDS to have a 
setting, no idea who answered you that but he is wrong), and image is not 
prepared for that.

of course is still possible :)

anyway, today I would tackle a solution in a different way: I would open my app 
morph on an SDL2 window and not touch the word at all (opening a headless 
image). This is not possible in windows because when you do “headless” it just 
laugh at you, but is doable in the not-so-long term.

Esteban

> On 27 Aug 2016, at 13:39, Cyril Ferlicot D.  wrote:
> 
> Le 27/08/2016 à 13:18, stepharo a écrit :
>> 
>> 
>> YES!!!
>> 
>> Do you know how Settings works?
>> We can adapt it this way.
> 
> When I improved the deployment of Synectique Tools I asked to get a
> simple way to disable Spotter via a setting but I got as answer "No
> because you can do it by removing a global shortcut so it is not needed.".
> 
> People in companies don't have the time to learn how shortcuts work and
> how to remove one without impacting something else. And they don't have
> the time to check Spotter code to know how it is call.
> 
> If the image is able to have a deployment mode then I don't care how
> Spotter is disabled (setting or removing a shortcut). But for now we
> don't have it. :)
> 
>> I mean the User approach that Benjmain proposed and was pushed in Pharo
>> was not good because it was not modular. Now each part of the system
>> should be
>> defined in way that it can be set just as a setting.
>> We should not have
>> 
>> World
>>User current = ifTrue
>> 
>> But
>> 
>> World use: userSetting
>> 
>> and World should handle it.
>> There is way more to do :)
>> When you deploy on linux you should be able to say beSilent to the
>> system (do not write on places that you cannot).
>> Valentin works on it and we should continue
>> 
>> Stef
>> 
> 
> The fact that there is much more to do is the main reason for Pharo to
> do it and not the developer. The developer cannot know all the system
> and will not be able to protect the code of his company well because he
> will forget something as to disable ctrl+o+p (or he is a god developer!
> But everyone is not).
> 
> This is a large thing to do, so it would be cool that everyone keep that
> in mind to allow it little by little (as with the work of Valentin).
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

Re: [Pharo-dev] SmalltalkHub over https

[Max Leske]

We’ve set up Let’s Encrypt on our servers and while it’s cool it also requires 
some work around it. Most importantly you have to set up auto renewal (every 30 
days). And if you don’t get it right it will suck.

Also: use VPN :)

> On 27 Aug 2016, at 13:07, stepharo  wrote:
> 
> Time and ressources.
> We cannot do more else it will damage what we are doing.
> Now if somebody wants to help he is more than welcome.
> 
> Stef
>> since Let's Encrypt offers free certs, is there any reason why smalltalkhub 
>> is not yet served over https? Maybe limitation of Zinc?
>> 
>> I guess that's one benefit that we are such a small community that nobody 
>> nuked us yet... (e.g. every time you commit from free wifi (hotel, airport, 
>> caffee, ...) you give up your password).
>> 
>> Peter
>> 
>> 
> 
> 

Re: [Pharo-dev] About Pharo 60

[Cyril Ferlicot D.]

Le 27/08/2016 à 13:18, stepharo a écrit :
> 
> 
> YES!!!
> 
> Do you know how Settings works?
> We can adapt it this way.

When I improved the deployment of Synectique Tools I asked to get a
simple way to disable Spotter via a setting but I got as answer "No
because you can do it by removing a global shortcut so it is not needed.".

People in companies don't have the time to learn how shortcuts work and
how to remove one without impacting something else. And they don't have
the time to check Spotter code to know how it is call.

If the image is able to have a deployment mode then I don't care how
Spotter is disabled (setting or removing a shortcut). But for now we
don't have it. :)

> I mean the User approach that Benjmain proposed and was pushed in Pharo
> was not good because it was not modular. Now each part of the system
> should be
> defined in way that it can be set just as a setting.
> We should not have
> 
> World
> User current = ifTrue
> 
> But
> 
> World use: userSetting
> 
> and World should handle it.
> There is way more to do :)
> When you deploy on linux you should be able to say beSilent to the
> system (do not write on places that you cannot).
> Valentin works on it and we should continue
> 
> Stef
> 

The fact that there is much more to do is the main reason for Pharo to
do it and not the developer. The developer cannot know all the system
and will not be able to protect the code of his company well because he
will forget something as to disable ctrl+o+p (or he is a god developer!
But everyone is not).

This is a large thing to do, so it would be cool that everyone keep that
in mind to allow it little by little (as with the work of Valentin).

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

[Hernán Morales Durand]

Just checked and the download URL is working.
If you send me mirror URLs then I can update the configuration to support
multiple download locations.

Cheers,

Hernán


2016-08-27 5:46 GMT-03:00 Peter Uhnak :

> Hi,
>
> GitFileTree / IceBerg is now broken, because ProcessWrapper (one of the
> deps on Windows) is downloading plugin from
>
> http://leves.web.elte.hu/ProcessWrapper/ProcessWrapperPlugin.dll
>
> But of course since the domain is down, it breaks everything.
>
> Not the mention downloading dll over http.
>
> Peter
>
>

Re: [Pharo-dev] About Pharo 60

[stepharo]

Hi!

There is one thing I would like, but maybe not for Pharo6 since there is
a lot to do, but I would like people to have this in mind: A way to
deploy commercials apps.


YES!!!



I would like to be able to say something like "Smalltalk
lockForDeployment" and "Smalltalk prepareForDeployment" for example.

The first one could just lock the access to the image and let a way to
get them back if you have a password. The second could unload everything
that you don't want for production if you don't plan to debug the image
if there is a problem.

Do you know how Settings works?
We can adapt it this way.
I mean the User approach that Benjmain proposed and was pushed in Pharo
was not good because it was not modular. Now each part of the system 
should be

defined in way that it can be set just as a setting.
We should not have

World
User current = ifTrue

But

World use: userSetting

and World should handle it.

At Synectique when we had a desktop application it was really hard to
lock everything :(
- Disable Halo
- Disable Spotter
- Disable the shortcuts to open a playground, a Nautilus, anything else
that the application
- Remove the private repositories and credentials just in case the
client find a way to get through and get a Monticello
- …

We should not have to do all that. Else Pharo will only be used to build
commencial web applications where the image is on the company's server
and not on the client's server. :(

There is way more to do :)
When you deploy on linux you should be able to say beSilent to the 
system (do not write on places that you cannot).

Valentin works on it and we should continue

Stef

Re: [Pharo-dev] Nautilus support for class method tests, and a bugfix for test result icons not resetting when a method is modified

[stepharo]

Tx Monty!

Apparently Jenkins infra is dead :)


Le 26/8/16 à 22:20, monty a écrit :

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

Re: [Pharo-dev] SmalltalkHub over https

[stepharo]

Time and ressources.
We cannot do more else it will damage what we are doing.
Now if somebody wants to help he is more than welcome.

Stef

since Let's Encrypt offers free certs, is there any reason why smalltalkhub is 
not yet served over https? Maybe limitation of Zinc?

I guess that's one benefit that we are such a small community that nobody nuked 
us yet... (e.g. every time you commit from free wifi (hotel, airport, caffee, 
...) you give up your password).

Peter

Re: [Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

[Esteban Lorenzano]

Hi,

Just a clarification: This is because of gitfiletree. In next versions of 
iceberg, we will not use ProcessWrapper (or OSSubprocess).

Esteban

> On 27 Aug 2016, at 11:01, stepharo  wrote:
> 
> Once you have the file we can mirror it on our server.
> 
> I always think about replication but this is not always the case.
> 
> Stef
> 
> 
>> Le 27/8/16 à 10:46, Peter Uhnak a écrit :
>> Hi,
>> 
>> GitFileTree / IceBerg is now broken, because ProcessWrapper (one of the deps 
>> on Windows) is downloading plugin from
>> 
>> http://leves.web.elte.hu/ProcessWrapper/ProcessWrapperPlugin.dll
>> 
>> But of course since the domain is down, it breaks everything.
>> 
>> Not the mention downloading dll over http.
>> 
>> Peter
> 
> 

Re: [Pharo-dev] About Pharo 60

[Cyril Ferlicot D.]

Le 24/08/2016 à 06:59, stepharo a écrit :
> Hi
> 
> We have some ideas (because people are working on items) for the Pharo 6
> roadmap
> 
> and we will consolidate them soon and propose them to you.
> 
> but I would like to know two kinds of points
> 
> - what are the points you are working on and that would deserve more
> focus and help from the community?
> 
> (these points are important because like that you could go
> faster and this is a good feeling to get done for example)
> 
> - what would be points where (if magically we would get more
> resources - to not dream if this is not you
> 
> there is a high chance that we will not make it) it would be
> nice to get some changes
> 
> 
> Please pay attention that if you type too fast and come up with a
> christmas list well it will stay a christmas list and will just make the
> thread larger for nothing.
> 
> Stef
> 
> 


Hi!

There is one thing I would like, but maybe not for Pharo6 since there is
a lot to do, but I would like people to have this in mind: A way to
deploy commercials apps.

I would like to be able to say something like "Smalltalk
lockForDeployment" and "Smalltalk prepareForDeployment" for example.

The first one could just lock the access to the image and let a way to
get them back if you have a password. The second could unload everything
that you don't want for production if you don't plan to debug the image
if there is a problem.

At Synectique when we had a desktop application it was really hard to
lock everything :(
- Disable Halo
- Disable Spotter
- Disable the shortcuts to open a playground, a Nautilus, anything else
that the application
- Remove the private repositories and credentials just in case the
client find a way to get through and get a Monticello
- …

We should not have to do all that. Else Pharo will only be used to build
commencial web applications where the image is on the company's server
and not on the client's server. :(

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] MorphicDoc?

[Nicolai Hess]

Anyone knows what is MorphicDoc (Kilon?)
I loaded the stable configuration in Pharo 5.0, but I can not find any
content.

(missing dependencies / packagese maybe ? )

Re: [Pharo-dev] About better communication in the community

[stepharo]

May be we should take the one of Pharo30 and review all the code.


Le 27/8/16 à 10:51, stepharo a écrit :
I took the inspector from Pharo20 and I will check if it is working in 
Pharo.

Then I will
- check EyeInspector from a package perspective (extensions and 
the rest)

- make sure that we can remove EyeInspector
- package the attached file as BasicInspector.

Now if you want to help you are welcome.

Stef

Re: [Pharo-dev] Fraction and isPowerOfTwo

[stepharo]

Please please please you see we need pythondoc like things

let us start by adding




I know it is wrong because I did not get it :)


Stef


Le 27/8/16 à 03:04, Nicolai Hess a écrit :



2016-08-27 2:21 GMT+02:00 monty >:


2^-5 = (1/32)


Ah, ok.

[Pharo-dev] SmalltalkHub over https

[Peter Uhnak]

Hi,

since Let's Encrypt offers free certs, is there any reason why smalltalkhub is 
not yet served over https? Maybe limitation of Zinc?

I guess that's one benefit that we are such a small community that nobody nuked 
us yet... (e.g. every time you commit from free wifi (hotel, airport, caffee, 
...) you give up your password).

Peter

Re: [Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

[stepharo]

Once you have the file we can mirror it on our server.

I always think about replication but this is not always the case.

Stef


Le 27/8/16 à 10:46, Peter Uhnak a écrit :

Hi,

GitFileTree / IceBerg is now broken, because ProcessWrapper (one of the deps on 
Windows) is downloading plugin from

http://leves.web.elte.hu/ProcessWrapper/ProcessWrapperPlugin.dll

But of course since the domain is down, it breaks everything.

Not the mention downloading dll over http.

Peter

Re: [Pharo-dev] About better communication in the community

[stepharo]

You see hernan doing positively is the best way to make that things happen

We can have a

preUnload hook

Now we should check how it fits with cleanForProduction and others.

But we should definitively have a way to express this.

So let us see how we can design it and then just implement it. I'm sure 
that GT people are open to such hooks


and if you really want to get a better Pharo for you then talk to them 
and us.



https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA

https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-SpecDebugger

https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-GT-Debugger

https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT

Stef

Re: [Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

[Guillermo Polito]

Hi peter,  just one note from the airport. It's Iceberg, not IceBerg. It is
not a compound word, but a single one.

Guille

Le 27 août 2016 10:47, "Peter Uhnak"  a écrit :

> Hi,
>
> GitFileTree / IceBerg is now broken, because ProcessWrapper (one of the
> deps on Windows) is downloading plugin from
>
> http://leves.web.elte.hu/ProcessWrapper/ProcessWrapperPlugin.dll
>
> But of course since the domain is down, it breaks everything.
>
> Not the mention downloading dll over http.
>
> Peter
>
>

Re: [Pharo-dev] About better communication in the community

[stepharo]

I took the inspector from Pharo20 and I will check if it is working in 
Pharo.

Then I will
- check EyeInspector from a package perspective (extensions and the 
rest)

- make sure that we can remove EyeInspector
- package the attached file as BasicInspector.

Now if you want to help you are welcome.

Stef
Model subclass: #Inspector
instanceVariableNames: 'contents object selectionIndex 
timeOfLastListUpdate selectionUpdateTime'
classVariableNames: ''
poolDictionaries: ''
category: 'Tools-Inspector'!
!Inspector commentStamp: '' prior: 0!
I represent a query path into the internal representation of an object. As a 
StringHolder, the string I represent is the value of the currently selected 
variable of the observed object.!


!Inspector methodsFor: '*Polymorph-TaskbarIcons' stamp: 'FernandoOlivero 
4/12/2011 09:47'!
taskbarIcon 
^ self theme smallInspectItIcon! !


!Inspector methodsFor: '*Shout-Parsing' stamp: 'SeanDeNigris 6/22/2012 18:34'!
shoutParser: anSHParserST80

anSHParserST80 isMethod: false.! !


!Inspector methodsFor: '*Shout-Styling' stamp: 'GuillermoPolito 1/17/2012 
14:09'!
shoutAboutToStyle: aPluggableShoutMorphOrView 
aPluggableShoutMorphOrView getTextSelector == self trashSelector 
ifFalse: [ ^false ].
aPluggableShoutMorphOrView classOrMetaClass: self object class.
^ true! !


!Inspector methodsFor: '*necompletion' stamp: 'SeanDeNigris 7/7/2012 22:49'!
guessTypeForName: aString

self flag: 'we may be able to do something more sophisticated here, but 
needed something to prevent a DNU. Returning nil was taken from AbstractTool. 
See Debugger or Workspace for actual guessing logic'.
^ nil.! !

!Inspector methodsFor: '*necompletion' stamp: 'SeanDeNigris 6/22/2012 16:21'!
isCodeCompletionAllowed

^ true.! !


!Inspector methodsFor: 'accessing'!
baseFieldList
"Answer an Array consisting of 'self'
and the instance variable names of the inspected object."

^ (Array with: 'self' with: 'all inst vars')
, object class allInstVarNames! !

!Inspector methodsFor: 'accessing' stamp: 'GuillermoPolito 8/12/2010 14:52'!
contents
^contents! !

!Inspector methodsFor: 'accessing' stamp: 'GuillermoPolito 8/12/2010 14:52'!
contentsSelection
"Return the interval of text in the code pane to select when I set the 
pane's contents"

^ 1 to: 0  "null selection"! !

!Inspector methodsFor: 'accessing'!
fieldList
"Answer the base field list plus an abbreviated list of indices."

object class isVariable ifFalse: [^ self baseFieldList].
^ self baseFieldList ,
(object basicSize <= (self i1 + self i2)
ifTrue: [(1 to: object basicSize)
collect: [:i | i printString]]
ifFalse: [(1 to: self i1) , (object basicSize-(self 
i2-1) to: object basicSize)
collect: [:i | i 
printString]])! !

!Inspector methodsFor: 'accessing'!
i1
"This is the max index shown before skipping to the 
last i2 elements of very long arrays"
^ 100! !

!Inspector methodsFor: 'accessing'!
i2
"This is the number of elements to show at the end
of very long arrays"
^ 10! !

!Inspector methodsFor: 'accessing' stamp: 'al 9/21/2008 19:40'!
initialExtent
"Answer the desired extent for the receiver when it is first opened on 
the screen.  "

^ 350 @ 300! !

!Inspector methodsFor: 'accessing' stamp: 'sd 11/20/2005 21:27'!
modelWakeUpIn: aWindow
| newText |
self updateListsAndCodeIn: aWindow.
newText := self contentsIsString
ifTrue: [newText := self selection]
ifFalse: ["keep it short to reduce time to compute it"
self selectionPrintString ].
newText = contents ifFalse:
[contents := newText.
self changed: #contents]! !

!Inspector methodsFor: 'accessing' stamp: 'sd 11/20/2005 21:27'!
noteSelectionIndex: anInteger for: aSymbol
aSymbol == #fieldList
ifTrue:
[selectionIndex := anInteger]! !

!Inspector methodsFor: 'accessing'!
object
"Answer the object being inspected by the receiver."

^object! !

!Inspector methodsFor: 'accessing' stamp: 'sd 11/20/2005 21:27'!
object: anObject 
"Set anObject to be the object being inspected by the receiver."

| oldIndex |
anObject == object
ifTrue: [self update]
ifFalse:
[oldIndex := selectionIndex <= 2 ifTrue: 
[selectionIndex] ifFalse: [0].
self inspect: anObject.
oldIndex := oldIndex min: self fieldList size.
self changed: #inspectObject.
oldIndex > 0
 

Re: [Pharo-dev] About better communication in the community

[stepharo]

What we should do is to add an unload method to each of the package 
manifest of the corresponding projects.


We should make the unload protocol a lot more present.

I will start with Nautilus.



Can you publish the unload process?


Workspace openContents: 'GTPlayground setGTPlaygroundEnabledStatus: false.
" == Debuggers == "

Nautilus pluginClasses: nil.
SpecDebugger closeAllDebuggers.
GTGenericStackDebugger closeAllDebuggers.
GTGenericStackDebugger setGTDebuggerEnabledStatus: false.

" == Miscellany == "

GTInspector setGTInspectorEnabledStatus: false.
GTExampleOrganizer stop.
GTEventRecorder cleanUp.
GTEventRecorderSettings cleanUp.
GTSnippets reset.
GTPlayBook reset.
GTPlayBook resetDirectories.
GTSpotter cleanUp.
GTSpotterGlobalShortcut reset.

GlobalIdentifier cleanUp.
Privacy cleanUp.

" == QA == "
QASettings inspectorPluggin: false.
QASettings spotterPlugin: false.
QAEventCollector unload.
(MCPackage named: ''QualityAssistant'') unload.

" == RPackage == "
RPackageOrganizer default packageNames
select: [ :each | each beginsWith: ''GT'' ]
thenDo: [ :each |
(MCPackage named: each) unload.
RPackageOrganizer default unregisterPackageNamed: each.
" Possibly unnecessary... "
Smalltalk removeEmptyMessageCategories.
Smalltalk cleanOutUndeclared.
Smalltalk fixObsoleteReferences.
Smalltalk globals flushClassNameCache ].

Behavior flushEvents.
Behavior flushObsoleteSubclasses.
SmalltalkImage current resetTools.'

I still have some obsoletes around

AnObsoleteGTSpotterGlobalShortcut .
AnObsoleteQANautilusPlugin .
AnObsoleteGTExampleFinder
AnObsoleteGTExampleOrganizer
AnObsoleteGTSpotterProfiler
AnObsoleteGTEventCollector
AnObsoleteGTExampleNotDefinedRule

Tried to clean but no sucess so far.


Respect the freedom of choice for people which is not obligated
to love all your tools, by providing an uninstall option (if the
tool is not really essential)

I agree about the Unload Joseph Pelrine always told me that we
are only done when we can
upload and that the system is in a good shape.

You may not know it because I spent days working on configuration
of RB and friends
The problems is that it is a hell to keep them up to date (because
of our image).
We should have a building process from a seed. Because like that
you experiment every single day that you loading script.
Now we did not stress enough the unload of Metacello.


Now you see Pharo cannot be an empty shell.
Because what will happen if we are always listening to someone
that does not like something.
Now I strongly encourage you to watch the esug talk about
bootstrap because with it and all the work
of Pavel to define configurations for all the part of the system
so people will be able to build their solutions when the
official version does not suite their needs.




I would love to have the time to invite you, or any GT
developer, to work with me just one week with real DNA data,
and see how well GT goes...


Please do a skype sharing session with Andrei and Doru. I'm
sure that they will love to do it.
So I take your words and urge you do it.
It will help you to get out your frsutration and I'm sure
that GT will improve.
So a clear win/win situation.


This is hard for me because I'm sure at this point Andrei and
Doru should be angry with me for ciriticizing their work.

No I do not think so :)
I criticized their tools too.

But I will try to make some use cases these days and share with
you so I can show you specifically what I'm talking about.

Excellent!


Understood, what makes me most sad is users almost accepted
they cannot do better and if they do, their work will never
be integrated by default.

No do better.
Why I started Spec when ther was Glamour. Why Alain was
working on Calipso?
I would love that someone comes and tell me: take XX it is
super hyper cool UI Builder.


Me too, and by this point we should really ask ourselves why we
don't have yet a cool UI Builder.

Because nobody did it in a way that we can use it.

One guy worked alone on a private project long time ago. We could
not give him any feedback
because he wanted to have it perfect in the first place.
He stoped to work on it because of bad table support.
I looked at it once he opened-source it and you would not like to
have the code in Pharo.

Stef



Hernán


Instead, non-voters decisions discourages users to be
rewarded for their creativity, and imposes many others to
work free "supporting" tools which were imposed de facto.

So again, I cannot stress this enough: Is my job to say
no. I know I hurt some 

[Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

[Peter Uhnak]

Hi,

GitFileTree / IceBerg is now broken, because ProcessWrapper (one of the deps on 
Windows) is downloading plugin from

http://leves.web.elte.hu/ProcessWrapper/ProcessWrapperPlugin.dll

But of course since the domain is down, it breaks everything.

Not the mention downloading dll over http.

Peter

[Pharo-dev] IceBerg and push for projects vs packages

[Peter Uhnak]

Hi,

one thing that I wanted to ask about IceBerg --- during the IceBerg talk Nico 
mentioned that we need to think in terms of projects.

Now I understand that perspective, because that's how git behaves and that's 
how _I_ think,

however at the same time, there is a strong push for focusing on packages... 
having each package describing it's dependencies, etc.

So my question is, how do those two views interact with each other? Because I 
feel like they are going against each other.

Peter

Re: [Pharo-dev] CI is down

[Marcus Denker]

something is in a strange state… the update from yesterday afternoon (there 
should be a 194) is not there,
it is very slow… but it seems to work.

Sadly I am *completely* dead after esug and will be offline the weekend.

Marcus
> On 26 Aug 2016, at 01:05, monty  wrote:
> 
> https://ci.inria.fr/pharo
>