Re: [Pharo-dev] OSProcess in 3.0

[David T. Lewis]

On Tue, Oct 14, 2014 at 09:35:44PM +0200, Thierry Goubier wrote:
> 
> 
> Le 14/10/2014 14:15, David T. Lewis a ?crit :
> >On Tue, Oct 14, 2014 at 07:19:10AM +0200, Thierry Goubier wrote:
> >>Hi Dave,
> >>
> >>took me a while to do some testing. It seems there is an issue, but I
> >>couldn't find out where. First, the data:
> >>
> >>Loading a package from a local gitfiletree repository (get from the
> >>command a zipped git archive containing the package) :
> >>
> >>4.5.11, 4.6.8: 2132 msec.
> >>4.5.12, 4.6.9: 50847 msec.
> >>
> >>I tried to rewrite the main command, remove the closePipes, etc... No
> >>change in the runtime, so your right.
> >>
> >>Profiling doesn't help much: execution time is mostly idle time (but
> >>with a significant increase on PipeableOSProcess commands: goes from
> >>invisible to 2700 ms. A user break in the middle shows it delay waiting
> >>on output of the external process).
> >>
> >>Only hint I could see is that it seems to be linked with the size of the
> >>output of the command.
> >
> >Thierry,
> >
> >Aha! I am quite sure that you have located the problem. There must be
> >something preventing the OS process from running to completion with
> >a larger amount of output data. It definitely sounds like a bug in my
> >latest update to Pipeable OSProcess.
> 
> The strange thing is that it runs to completion (i.e. I got no errors; 
> if any data was missing or corrupted on output, my load would fail); but 
> a lot slower than it should be.
> 
> >Thank you very much for finding this. I will get it fixed as quickly
> >as I can.
> 
> Thanks. I'm unable to help you much, I'm afraid :(

Thierry,

I do not yet have a solution to this, but I have been able to confirm
that the performance difference that you see is primarily associated with
the AioPlugin not being present in your VM.

When I changed PipeableOSProcess to handle pipe handle closing properly,
I used a buffered output stream that is driven by aio events. When data
is available to be read from the external OS process, an aio notification
pulls the available data into the buffered stream, and when no more data
is available, the pipe (file) handles are closed.

If the plugin is not present in the VM, I provided a polling mechanism
to read data from the external OS process. Apparently this is very
inefficient, and I am sure it could be greatly improved. That is the
cause of the extremely slow performance that you are seeing.

So in summary: The enhancement to PipeableOSProcess relies on an aio
event driven reader, and if the AIO plugin is missing, the fallback code
relies on polling, and is horribly inefficient.

More to follow, and thank you again for identifying the problem.

If you can convice your VM vendor to include AioPlugin in your VM, that
would be helpful also ;-)

Dave

Re: [Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello

[Sven Van Caekenberghe]

On 15 Oct 2014, at 21:57, p...@highoctane.be wrote:

> Nice!
> 
> I'll try the Announcers thing on a Seaside session.
> 
> How would you do that? I mean DynamicVariables in GT.
> 
> ​Phil

I am not sure I understand the question.

I did/do Announcement based logging in Seaside, just firing them globally. But 
I did add a session ID to each log event so that you can keep them apart.

My custom WASession subclass adds its #key and #username to the log event 
objects.

I'll send you some example output in private.

Sven

Re: [Pharo-dev] Tests around Pharo

[mschepens]

I finally managed the proxy problem by sending commits from my own web
connection.
So I put the issues to "Fix review needed". I had some problems while
importing Collections-Tests (Native part, for the FloatArrayTest) but
finally managed it too.

I sent to Damien Cassou the "license agreements" filled and signed, I will
give him my copy of this paper next wednesday.

Hope our tests will be helpful and will increase test coverage of pharo, it
was really interesting for us to work on this project, and we acquired
significant knowledges (about smalltalk but about opensource projects too).
We'll follow our commits evolution, and again thanks to all of you for the
time you gave us !



--
View this message in context: 
http://forum.world.st/Tests-around-Pharo-tp4777295p4784793.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello

[p...@highoctane.be]

Nice!

I'll try the Announcers thing on a Seaside session.

How would you do that? I mean DynamicVariables in GT.

​Phil

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Eliot Miranda]

On Wed, Oct 15, 2014 at 11:53 AM, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:

> Eliot Miranda-2 wrote
> > On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
>
> > richard.sargent@
>
> >> wrote:
> >> One of the best things about Smalltalk is how easily we can say what we
> >> mean. I think you would be better off creating a method named something
> >> like
> >> #hasSameEffectAs: to answer what you are presently using #= to do, and
> >> change #= to answer the, in my opinion, more sensible "is the same as"
> >> that
> >> we conventionally think of #= meaning.
> >>
> >
> > But that's the point.  #= has to mean something and having it mean #==
> > isn't useful, so one has to choose some value-based semantic for
> > CompiledMethod>>#= and the one that's there is useful.  Defining what #=
> > means for some value type is far easier than defining what it might mean
> > for something as complex as a CompiledMethod.  The definition in
> > Squeak/Pharo has been useful to me in implementing a closure-based
> system,
> > so I'm unapologetic about the current definition.  It is a good one but
> it
> > doesn't preclude defining others.
>
> An interesting response. You ignored the point that e.g. #hasSameEffectAs:
> provides greater clarity and add an argument against something I didn't
> say.
>

It's a given.  But the selector still isn't perfectly informative, see
below.  And what's the effect?  The effect when executed, so why not
hasSameEffectWhenExecuted:? It's a mouthful.

I also don't think defining equality for a CompiledMethod is particularly
> difficult. If I were to recompile a method's source code, I would get a new
> instance of a CompiledMethod that would, in my opinion, be equal to the one
> already installed in the class (and perhaps cached in the VM's
> optimizations). So one would be able to say that we would not replace an
> existing CompiledMethod with an equal one. The current implementation of #=
> has no such characteristic, since it proclaims a CompiledMethod named #a to
> be equal to one named #z.
>

And for some uses that is correct, one names a /is/ equal to one named z,
even though their selectors differ.  For example if you do the following:

 aClass compile: 'a ^1'; compile: 'b ^ 1'.
 aClass compiledMethodAt: #a put: aClass >> #b

then "aClass new a" still answers 1.  It's only if one introspects
(thisContext method selector, opens the debugger, etc) that one sees that
the selector doesn't match.  If you go back to Smalltalk-80 you'll see that
compiled methods didn't store their selector and to find out their selector
one searched the method dictionary of the method's method class.  As far as
what most methods do (excluding introspecting code) the selector is merely
a cache of the key in the relevant method dictionary.

So #hasSameEffect: *doesn't* mean what one might think it means for some
uses (it doesn't only depend on the method in question, but on usage,
whether the method is used in an introspective context, etc).  So naming a
more explanatory selector is more difficult than you might think.

The blue book say #= means "Answer whether the receiver and the argument
> represent the same component." The current implementation does so only for
> some, in my opinion, counter-intuitive definition of "same component".
>

Well Smalltalk-80 says
Answer true if the receiver and the argument represent the same object
and false otherwise. If = is redefined in any subclass, consider also
redefining the message hash.

and that's just as vague (AFAIA the blue book doesn't define what a
component is), because whether objects are equal or not depends on usage.
In the end the system is full of definitions of #= which are more or less
generally useful in various contexts.  Things are easy for the arithmetic
types, but for more complex objects there are always caveats

| s1 s2 |
s1 := Set new.
s1 add: s1.
s2 := Set new.
s2 add: s2.
s1 = s2

doesn't terminate.  So should Set's #= be called isEqualIfNonRecursive: ?
No.  Its limited #= is fine in practice and much better than Smalltalk-80's
original fall back to #==.  But it is not a perfect equality.  Neither is
CompiledMethod's.  But it being imperfect is not an argument for changing
it to another, inevitably also flawed definition without good reason.

--
> View this message in context:
> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>

-- 
best,
Eliot

Re: [Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello

[Tudor Girba]

Nice! :)

Doru

On Wed, Oct 15, 2014 at 3:55 PM, Sven Van Caekenberghe  wrote:

> Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello.
>
> I love it when a plan comes together. Many small usability changes were
> added to GT Tools since they were included in Pharo 4. And a lot of small
> custom inspector presentations were added.
>
>   http://youtu.be/rIBbeMdFCys  (be sure to select the 720p version)
>
> This short screencast shows how to use ZnLogEvents and GT Tools in Pharo 4
> to look at the HTTP traffic behing Monticello (more specifically, an
> MCSmalltalkhubRepository). This demonstrates how simple custom inspectors
> are combined to form a powerful tool - and how easy it is to learn about
> what is going on inside Pharo.
>
> Sven
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Richard Sargent]

Eliot Miranda-2 wrote
> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <

> richard.sargent@

>> wrote:
>> One of the best things about Smalltalk is how easily we can say what we
>> mean. I think you would be better off creating a method named something
>> like
>> #hasSameEffectAs: to answer what you are presently using #= to do, and
>> change #= to answer the, in my opinion, more sensible "is the same as"
>> that
>> we conventionally think of #= meaning.
>>
> 
> But that's the point.  #= has to mean something and having it mean #==
> isn't useful, so one has to choose some value-based semantic for
> CompiledMethod>>#= and the one that's there is useful.  Defining what #=
> means for some value type is far easier than defining what it might mean
> for something as complex as a CompiledMethod.  The definition in
> Squeak/Pharo has been useful to me in implementing a closure-based system,
> so I'm unapologetic about the current definition.  It is a good one but it
> doesn't preclude defining others.

An interesting response. You ignored the point that e.g. #hasSameEffectAs:
provides greater clarity and add an argument against something I didn't say.

I also don't think defining equality for a CompiledMethod is particularly
difficult. If I were to recompile a method's source code, I would get a new
instance of a CompiledMethod that would, in my opinion, be equal to the one
already installed in the class (and perhaps cached in the VM's
optimizations). So one would be able to say that we would not replace an
existing CompiledMethod with an equal one. The current implementation of #=
has no such characteristic, since it proclaims a CompiledMethod named #a to
be equal to one named #z.

The blue book say #= means "Answer whether the receiver and the argument
represent the same component." The current implementation does so only for
some, in my opinion, counter-intuitive definition of "same component".




--
View this message in context: 
http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784779.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Eliot Miranda]

Hi Richard,

On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent <
richard.sarg...@gemtalksystems.com> wrote:

> Eliot Miranda-2 wrote
> > I responded...
>
> I have to disagree with your recommendation. You say that you intend #= to
> mean "has the same effect as" rather than "is the same as".
>
> One of the best things about Smalltalk is how easily we can say what we
> mean. I think you would be better off creating a method named something
> like
> #hasSameEffectAs: to answer what you are presently using #= to do, and
> change #= to answer the, in my opinion, more sensible "is the same as" that
> we conventionally think of #= meaning.
>

But that's the point.  #= has to mean something and having it mean #==
isn't useful, so one has to choose some value-based semantic for
CompiledMethod>>#= and the one that's there is useful.  Defining what #=
means for some value type is far easier than defining what it might mean
for something as complex as a CompiledMethod.  The definition in
Squeak/Pharo has been useful to me in implementing a closure-based system,
so I'm unapologetic about the current definition.  It is a good one but it
doesn't preclude defining others.

$0.02 worth and worth everything you paid for it. :-)
> Richard
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784771.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>


-- 
best,
Eliot

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Richard Sargent]

Eliot Miranda-2 wrote
> I responded...

I have to disagree with your recommendation. You say that you intend #= to
mean "has the same effect as" rather than "is the same as". 

One of the best things about Smalltalk is how easily we can say what we
mean. I think you would be better off creating a method named something like
#hasSameEffectAs: to answer what you are presently using #= to do, and
change #= to answer the, in my opinion, more sensible "is the same as" that
we conventionally think of #= meaning.


$0.02 worth and worth everything you paid for it. :-)
Richard




--
View this message in context: 
http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p4784771.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

[Eliot Miranda]

I responded...

On Wed, Oct 15, 2014 at 7:11 AM, Max Leske  wrote:

> We found an issue where CompiledMethods can produce the same hash event
> within the same MethodDictionary. Reported here:
>
>
> https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-clashes
>
> Cheers,
> Max
>



-- 
best,
Eliot

Re: [Pharo-dev] Context variables?

[Camille Teruel]

Hi Jeff,

I think you should look at DynamicVariable and ProcessSpecificVariable classes. 
The first one is a read-only while the second is writable.
You have to subclass these class for each variable you want.

Ex:
DynamicVariable subclass: #MyVar.
MyVar value: 4 during: [ MyVar value ]

HTH,
Camiile


On 15 oct. 2014, at 17:09, J.F. Rick  wrote:

> I remember there was some discussion on the list about support for variables 
> tied to the context rather than to the instance or class. This seems 
> particularly useful for a web application where you might want to access the 
> request and response from the context. What is the proper name for these kind 
> of variables and where can I read about how to use them?
> 
> Cheers,
> 
> Jeff
> 
> -- 
> Jochen "Jeff" Rick, Ph.D.
> http://www.je77.com/
> Skype ID: jochenrick

[Pharo-dev] Context variables?

[J.F. Rick]

I remember there was some discussion on the list about support for
variables tied to the context rather than to the instance or class. This
seems particularly useful for a web application where you might want to
access the request and response from the context. What is the proper name
for these kind of variables and where can I read about how to use them?

Cheers,

Jeff

-- 
Jochen "Jeff" Rick, Ph.D.
http://www.je77.com/
Skype ID: jochenrick

[Pharo-dev] [Pharo4] Properties for classes

[Marcus Denker]

Hi,

Methods, AST Nodes and all Ring Definitions can store properties. 
Now in Pharo4 update 307, Yuriy Tymchuk extended this idea to Behaviors.

They are not stored when saving code (filing out or MC), as this would be on 
top (as are the Pragmas on Methods build on top of properties).

TODO
-> unify API across RB/CompiledMethod/Ring
-> add properties to the Variable meta-objects (there is already a 
proof-of-concept in class
LinkWrapper for one special kind of property)
-> For sure there are bugs (while writing this I had one idea of one 
already… need to check)

This will not be used by the system itself for now, therefore we opted
to store them not in an ivar but a classVar dictionary, so they do not take
any space when not used (like CompiledMethod properties where realised in the
beginning, too).

Marcus

Re: [Pharo-dev] creating custom browsers out of GTInspector extensions

[Hilaire]

Le 14/10/2014 23:26, Tudor Girba a écrit :
> Now, that more people are playing with the GTInspector, I would like to
> raise another point that might otherwise go unnoticed: The inspector
> extensions do not only work in the inspector, but can also be combined
> in other browsers as well.
> 

It really looks intersting! I can imagine some good use of it to
navigate in geometric objects.

Thanks

Hilaire

-- 
Dr. Geo - http://drgeo.eu
iStoa - http://istoa.drgeo.eu

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40307
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 436ad6: 40307

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 436ad6373a606492b003f3a2aa13db8772dc9d85
  
https://github.com/pharo-project/pharo-core/commit/436ad6373a606492b003f3a2aa13db8772dc9d85
  Author: Jenkins Build Server 
  Date:   2014-10-15 (Wed, 15 Oct 2014)

  Changed paths:
M Kernel.package/Behavior.class/class/class initialization/initialize.st
A Kernel.package/Behavior.class/class/class 
initialization/initializeClassProperties.st
M Kernel.package/Behavior.class/definition.st
A Kernel.package/Behavior.class/instance/accessing-properties/properties.st
A 
Kernel.package/Behavior.class/instance/accessing-properties/removePropertiesIfEmpty.st
A KernelTests.package/BehaviorTest.class/instance/test - 
properties/testPropertyValueAtPut.st
A KernelTests.package/BehaviorTest.class/instance/test - 
properties/testRemoveProperty.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script307.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40307.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A Traits.package/TBehavior.class/instance/accessing-properties/properties.st
A 
Traits.package/TBehavior.class/instance/accessing-properties/propertyValueAt_.st
A 
Traits.package/TBehavior.class/instance/accessing-properties/propertyValueAt_ifAbsent_.st
A 
Traits.package/TBehavior.class/instance/accessing-properties/propertyValueAt_put_.st
A 
Traits.package/TBehavior.class/instance/accessing-properties/removePropertiesIfEmpty.st
A 
Traits.package/TBehavior.class/instance/accessing-properties/removeProperty_.st
A 
Traits.package/TBehavior.class/instance/accessing-properties/removeProperty_ifAbsent_.st
A Traits.package/TraitBehavior.class/class/initialization/initialize.st
M Traits.package/TraitBehavior.class/definition.st
A 
Traits.package/TraitBehavior.class/instance/accessing-properties/properties.st
A 
Traits.package/TraitBehavior.class/instance/accessing-properties/removePropertiesIfEmpty.st

  Log Message:
  ---
  40307
14177 Add properties to classes
https://pharo.fogbugz.com/f/cases/14177

http://files.pharo.org/image/40/40307.zip

[Pharo-dev] CompiledMethod>>hash can produce clashes

[Max Leske]

We found an issue where CompiledMethods can produce the same hash event within 
the same MethodDictionary. Reported here:

https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-clashes 


Cheers,
Max

[Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello

[Sven Van Caekenberghe]

Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello.

I love it when a plan comes together. Many small usability changes were added 
to GT Tools since they were included in Pharo 4. And a lot of small custom 
inspector presentations were added.

  http://youtu.be/rIBbeMdFCys  (be sure to select the 720p version)

This short screencast shows how to use ZnLogEvents and GT Tools in Pharo 4 to 
look at the HTTP traffic behing Monticello (more specifically, an 
MCSmalltalkhubRepository). This demonstrates how simple custom inspectors are 
combined to form a powerful tool - and how easy it is to learn about what is 
going on inside Pharo.

Sven

Re: [Pharo-dev] BlockClosure source code

[Christophe Demarey]

Le 15 oct. 2014 à 14:18, Ben Coman a écrit :

> Marcus Denker wrote:
>>> On 14 Oct 2014, at 16:42, Marcus Denker >> > wrote:
>>> 
 
 On 10 Oct 2014, at 12:29, Marcus Denker >>> > wrote:
 
 
> On 10 Oct 2014, at 10:57, Jan Kurš  > wrote:
> 
> Hi All,
> 
> Thank you for the replies. I see it is not an easy bug to fix. Do you 
> have any idea, when this can be fixed? 
 I will try to fix it next week...
 
> Or can you suggest me some other way/workaround, how to get/generate the 
> source code of a block?
> 
 
 The old compiler used a hack to decompile blocks for getting a textual 
 representation… one could port
 the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I 
 actually like the current scheme of
 using the byte code-offset-to-AST mapping more).
 
>>> 
>>> step one: A nice tool… GTInspector view of the byte codes that highlights 
>>> what is thinks is the corresponding code in the source.
>>> (This living Bytecode view replaces what before just printed out the 
>>> #longPrintString of the CompiledMethod):
>>> 
>> This is now in 4.0 update 306.
>> e.g. inspect OrderedCollection>>#do:
>> then select the “SymbolicBC” tab, click on a byte code, then select in the 
>> second view the “Source” tab.
>> ==> when moving around the byte code, the text highlights the code that 
>> generated the byte code.
>> Marcus
> 
> This is be great to pull more people into understanding (and helping) the 
> dark depths.  What about a tab in the second pane named "Help" that describes 
> what each bytecode does? (half serious)
> 
> For example, line 32, what is the "2" in "pushTemp: 2", and "1" in 
> "pushConstant: 1".

the index




smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] BlockClosure source code

[Ben Coman]

Marcus Denker wrote:


On 14 Oct 2014, at 16:42, Marcus Denker > wrote:




On 10 Oct 2014, at 12:29, Marcus Denker > wrote:



On 10 Oct 2014, at 10:57, Jan Kurš > wrote:


Hi All,

Thank you for the replies. I see it is not an easy bug to fix. Do 
you have any idea, when this can be fixed? 


I will try to fix it next week...

Or can you suggest me some other way/workaround, how to get/generate 
the source code of a block?




The old compiler used a hack to decompile blocks for getting a 
textual representation… one could port
the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I 
actually like the current scheme of

using the byte code-offset-to-AST mapping more).



step one: A nice tool… GTInspector view of the byte codes that 
highlights what is thinks is the corresponding code in the source.
(This living Bytecode view replaces what before just printed out the 
#longPrintString of the CompiledMethod):




This is now in 4.0 update 306.

e.g. inspect 


OrderedCollection>>#do:

then select the “SymbolicBC” tab, click on a byte code, then select in 
the second view the “Source” tab.
==> when moving around the byte code, the text highlights the code that 
generated the byte code.


Marcus



This is be great to pull more people into understanding (and helping) 
the dark depths.  What about a tab in the second pane named "Help" that 
describes what each bytecode does? (half serious)


For example, line 32, what is the "2" in "pushTemp: 2", and "1" in 
"pushConstant: 1".


cheers -ben

[Pharo-dev] [ANN] New Gold Member LabWare

[Marcus Denker]

The Pharo Consortium is very happy to announce that LabWare has joined the 
Consortium as a Gold Industrial Member. 

About LabWare:
"LabWare is recognized as the global leader in providing enterprise scale 
laboratory automation solutions.  
Our Enterprise Laboratory Platform combines the award-winning LabWare LIMS™ and 
LabWare ELN™, a 
comprehensive and fully integrated Electronic Laboratory Notebook application, 
which enables companies 
to optimize compliance, improve quality, increase productivity and reduce 
costs. LabWare is a full service 
provider offering software, professional implementation services and validation 
assistance, training, and 
world class technical support to ensure our customers get the maximum value 
from their LabWare products."

  - LabWare: http://www.labware.com
  - Pharo Consortium: http://consortium.pharo.org

The goal of the Pharo Consortium is to allow companies to support the ongoing 
development and future of Pharo.
Individuals can support Pharo via the Pharo Association:  
http://association.pharo.org

Re: [Pharo-dev] creating custom browsers out of GTInspector extensions

[S Krish]

Really Cool...!



On Wed, Oct 15, 2014 at 11:52 AM, Marcus Denker 
wrote:

>
> > On 14 Oct 2014, at 23:26, Tudor Girba  wrote:
> >
> > Hi,
> >
> > Now, that more people are playing with the GTInspector, I would like to
> raise another point that might otherwise go unnoticed: The inspector
> extensions do not only work in the inspector, but can also be combined in
> other browsers as well.
> >
>
> We could replace (most of) the FileBrowser by
>
> GLMPager new with: [ :pager |
>  pager show: [ :composite :file |
>   composite title: file basename.
>   file gtInspectorItemsIn: composite.
>   file gtInspectorContentsIn: composite ];
> title: 'FileBrowser' ];
>  openOn: FileSystem disk workingDirectory
>
>
>
> Where it replaces
>
> FileList linesOfCode
>
> ==> 1075
> (plus three more helper classes).
>
> Of course this does a little bit more, but most of that is at the wrong
> spot anyway.
> (editor for text files, API for file selection on the class side).
>
> Marcus
>

Re: [Pharo-dev] Tests around Pharo

[S Krish]

Using *cntlm *Proxy is an option in the cases where normal HTTP Proxy does
not work right


On Wed, Oct 15, 2014 at 5:26 PM, Sven Van Caekenberghe  wrote:

>
> On 15 Oct 2014, at 13:52, Christophe Demarey 
> wrote:
>
> >
> > Le 15 oct. 2014 à 13:01, Camille Teruel a écrit :
> >
> >>
> >> On 15 oct. 2014, at 12:35, mschepens 
> wrote:
> >>
> >>> After numerous tries, it was impossible for us to access to
> smaltalkhub from
> >>> our university at 11 o'clock, we'll try this evening or next days from
> our
> >>> personal connections.
> >>>
> >>
> >> Hi Mathieu,
> >>
> >> I teach at M5 this friday morning, so I can come to IAGL room around
> 12h15 to show you directly if you want.
> >> Tell me.
> >
> > It is just because University blocks all traffic.
> > They need to use an http proxy. I don't know if it is doable from a
> Pharo image.
>
> Sure, it is doable/available/working:
>
>   System > Settings > Network > Use HTTP proxy...
>
> But HTTP Proxies, especially weird or badly configured ones, are a known
> PITA.
>

Re: [Pharo-dev] Tests around Pharo

[Sven Van Caekenberghe]

On 15 Oct 2014, at 13:52, Christophe Demarey  
wrote:

> 
> Le 15 oct. 2014 à 13:01, Camille Teruel a écrit :
> 
>> 
>> On 15 oct. 2014, at 12:35, mschepens  wrote:
>> 
>>> After numerous tries, it was impossible for us to access to smaltalkhub from
>>> our university at 11 o'clock, we'll try this evening or next days from our
>>> personal connections.
>>> 
>> 
>> Hi Mathieu,
>> 
>> I teach at M5 this friday morning, so I can come to IAGL room around 12h15 
>> to show you directly if you want.
>> Tell me.
> 
> It is just because University blocks all traffic.
> They need to use an http proxy. I don't know if it is doable from a Pharo 
> image.

Sure, it is doable/available/working:

  System > Settings > Network > Use HTTP proxy...

But HTTP Proxies, especially weird or badly configured ones, are a known PITA. 

Re: [Pharo-dev] Tests around Pharo

[Christophe Demarey]

Le 15 oct. 2014 à 13:01, Camille Teruel a écrit :

> 
> On 15 oct. 2014, at 12:35, mschepens  wrote:
> 
>> After numerous tries, it was impossible for us to access to smaltalkhub from
>> our university at 11 o'clock, we'll try this evening or next days from our
>> personal connections.
>> 
> 
> Hi Mathieu,
> 
> I teach at M5 this friday morning, so I can come to IAGL room around 12h15 to 
> show you directly if you want.
> Tell me.

It is just because University blocks all traffic.
They need to use an http proxy. I don't know if it is doable from a Pharo image.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] Tests around Pharo

[Camille Teruel]

On 15 oct. 2014, at 12:35, mschepens  wrote:

> After numerous tries, it was impossible for us to access to smaltalkhub from
> our university at 11 o'clock, we'll try this evening or next days from our
> personal connections.
> 

Hi Mathieu,

I teach at M5 this friday morning, so I can come to IAGL room around 12h15 to 
show you directly if you want.
Tell me.

Camille

> 
> 
> --
> View this message in context: 
> http://forum.world.st/Tests-around-Pharo-tp4777295p4784680.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] RFB - anyone having that working properly under linux?

[p...@highoctane.be]

Hi,

Well, not really that.
I removed the method but the symptom remains.

Logging gives me:


RFBSession running
RFBSession send protocol version
RFBSession RFB 003.007

RFBSession viewer using protocol 3.7
RFBSession client shared: true
RFBSession a RFBSocket[connected] connected
RFBSession ignoring request for ZRLE encoding
RFBSession rfbEncodingCopyRect
RFBSession rfbEncodingTight
RFBSession using Hextile encoding
RFBSession rfbEncodingQualityLevel 6
RFBSession ignoring unknown encoding: 4294967073
RFBSession rfbEncodingLastRect
RFBSession enabling LastRect protocol extension
RFBSession rfbEncodingPointerPos
RFBSession enabling cursor position updates
RFBSession rfbEncodingRichCursor
RFBSession enabling full-colour cursor updates
RFBSession received rfbSetPixelFormat
RFBSession set pixel format: 32bpp, depth 24 LE, true colour 255,255,255
16+8+0
RFBSession colour map a WordArray(16711680 65280 255 0) an IntegerArray(0 0
0 0)
RFBSession before color table
RFBSession rfbSetPixelFormat done <-- added by me.

RFB: caught ConnectionClosed: Connection close while waiting for data.
RFB: caught ConnectionTimedOut: send data timeout; data not sent

Still blocked on that then...

What is your log giving?

Phil

​

Re: [Pharo-dev] BlockClosure source code

[Marcus Denker]

> On 14 Oct 2014, at 16:42, Marcus Denker  wrote:
> 
>> 
>> On 10 Oct 2014, at 12:29, Marcus Denker > > wrote:
>> 
>> 
>>> On 10 Oct 2014, at 10:57, Jan Kurš >> > wrote:
>>> 
>>> Hi All,
>>> 
>>> Thank you for the replies. I see it is not an easy bug to fix. Do you have 
>>> any idea, when this can be fixed? 
>>> 
>> I will try to fix it next week...
>> 
>>> Or can you suggest me some other way/workaround, how to get/generate the 
>>> source code of a block?
>>> 
>> 
>> The old compiler used a hack to decompile blocks for getting a textual 
>> representation… one could port
>> the code from Pharo2 to the Package OpalDecompiler in Pharo4. (but I 
>> actually like the current scheme of
>> using the byte code-offset-to-AST mapping more).
>> 
> 
> step one: A nice tool… GTInspector view of the byte codes that highlights 
> what is thinks is the corresponding code in the source.
> (This living Bytecode view replaces what before just printed out the 
> #longPrintString of the CompiledMethod):
> 

This is now in 4.0 update 306.

e.g. inspect 

OrderedCollection>>#do:

then select the “SymbolicBC” tab, click on a byte code, then select in the 
second view the “Source” tab.
==> when moving around the byte code, the text highlights the code that 
generated the byte code.

Marcus

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40306
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 768d1a: 40306

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 768d1a710df941b14ecbd149977d06782d928d88
  
https://github.com/pharo-project/pharo-core/commit/768d1a710df941b14ecbd149977d06782d928d88
  Author: Jenkins Build Server 
  Date:   2014-10-15 (Wed, 15 Oct 2014)

  Changed paths:
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/blockReturnTop.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/doDup.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/doPop.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/jump_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/jump_if_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/methodReturnConstant_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/methodReturnReceiver.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/methodReturnTop.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/popIntoLiteralVariable_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/popIntoReceiverVariable_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/popIntoRemoteTemp_inVectorAt_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/popIntoTemporaryVariable_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushActiveContext.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushClosureCopyNumCopiedValues_numArgs_blockSize_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushConsArrayWithElements_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushConstant_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushLiteralVariable_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushNewArrayOfSize_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushReceiver.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushReceiverVariable_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushRemoteTemp_inVectorAt_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/pushTemporaryVariable_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/send_super_numArgs_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/storeIntoLiteralVariable_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/storeIntoReceiverVariable_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/storeIntoRemoteTemp_inVectorAt_.st
M Kernel.package/SymbolicBytecodeBuilder.class/instance/instruction 
decoding/storeIntoTemporaryVariable_.st
A 
Kernel.package/SymbolicBytecodeBuilder.class/instance/private/addBytecode_.st
R Kernel.package/SymbolicBytecodeBuilder.class/instance/private/print_.st
A KernelTests.package/BehaviorTest.class/instance/tests/testCompile.st
A OpalTools.package/GTBytecodeBrowser.class/README.md
A OpalTools.package/GTBytecodeBrowser.class/definition.st
A OpalTools.package/GTBytecodeBrowser.class/instance/building/compose.st
A OpalTools.package/GTBytecodeBrowser.class/instance/building/sourceIn_.st
A OpalTools.package/GTBytecodeBrowser.class/instance/building/treeIn_.st
A 
OpalTools.package/extension/CompiledMethod/instance/gtInspectorSymbolicBytecodeIn_.st
A 
OpalTools.package/extension/SymbolicBytecode/instance/gtInspectorSourceCodeIn_.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script306.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40306.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A Traits.package/TBehavior.class/instance/accessing/allSlots.st
A Traits.package/TBehavior.class/instance/accessing/basicLocalSelectors.st

  Log Message:
  ---
  40306
14215 Fix for (Behavior new) compile: 
https://pharo.fogbugz.com/f/cases/14215

14237 SymbolicBytecodeBuilder: rename #print to #addBytecode:
https://pharo.fogbugz.com/f/cases/14237

14239 add inspector view for byte code with source highlighting
https://pharo.fogbugz.com/f/cases/14239

http://files.pharo.org/image/40/40306.zip

Re: [Pharo-dev] RFB - anyone having that working properly under linux?

[Max Leske]

Your have to remove RFBSocket>>waitForSendDoneFor:

It overrides a method in Socket and fixes a few legacy bugs in Squeak but now 
it breaks RFB.

Cheers,
Max

> On 15.10.2014, at 11:52, p...@highoctane.be wrote:
> 
> Hello,
> 
> I've been trying to get RFB running in Pharo.
> 
> So, installation was okay, I updated the Configuration to pick the last 
> change from Damien Cassou.
> 
> Still, I start the server with:
> 
> RFBServer current
> initializePreferences;
> configureForMemoryConservation;
> allowEmptyPasswords: false;
> setFullPassword: 'password'; "Clear text passwords..."
> setViewPassword: 'password'; "... urgh!"
> enableLogging: true;
> enableDebugging: true;
> start: 0.
> 
> along with RFBLog dumpLogToTranscript: true.
> 
> Server loads, starts.
> 
> Now, when I connect with RealVNC, or TightVNC, or OSX built-in VNC, I get a 
> view of the UI (so, a copy of the framebuffer is sent)
> 
> 
> 
> The error I get is (as I am in debugging mode):
> 
> 
> 
> I followed the contexts upwards in the exception to sendData:startingAt:count:
> 
> 
> 
> 
> I wonder why I do not get the VNC client going on as the first screen is sent 
> properly.
> 
> TIA
> 
> Phil

Re: [Pharo-dev] Tests around Pharo

[mschepens]

After numerous tries, it was impossible for us to access to smaltalkhub from
our university at 11 o'clock, we'll try this evening or next days from our
personal connections.



--
View this message in context: 
http://forum.world.st/Tests-around-Pharo-tp4777295p4784680.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] [pharo-project/pharo-core] 1ce6ea: 40305

[GitHub]

  Branch: refs/heads/4.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 1ce6eaf214fbe614c9ded6f72a2697afb938711d
  
https://github.com/pharo-project/pharo-core/commit/1ce6eaf214fbe614c9ded6f72a2697afb938711d
  Author: Jenkins Build Server 
  Date:   2014-10-15 (Wed, 15 Oct 2014)

  Changed paths:
A Kernel.package/SymbolicBytecode.class/instance/mapping/sourceInterval.st
A Kernel.package/SymbolicBytecode.class/instance/mapping/sourceNode.st
M 
Manifest-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForClassOrMethod_.st
M NECompletion.package/NOCCompletionTable.class/class/class 
initialization/initialize.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
scripts/script305.st
A ScriptLoader40.package/ScriptLoader.class/instance/pharo - 
updates/update40305.st
M 
ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  40305
13535 Class code wrongly styled in critic browser
https://pharo.fogbugz.com/f/cases/13535

14236 add #sourceInterval and #sourceNode to SymbolicBytecode
https://pharo.fogbugz.com/f/cases/14236

14238 Replace Announcer>>#on:send:to:s senders in NECompletion
https://pharo.fogbugz.com/f/cases/14238

http://files.pharo.org/image/40/40305.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/40305
  Home:   https://github.com/pharo-project/pharo-core