Re: [Pharo-users] How to remove method body?

[Stephane Ducasse]

Thanks steven

I was finally doing

| newTree |
newTree :=
(ObjSkeletonMock >> #methodToSkeletonize2) ast body:
(ObjSkeletonMock >> #returnSelf) ast body.
newTree formattedCode.
ObjSkeletonMock compile: newTree formattedCode classified: #foo



On Sun, Dec 3, 2017 at 11:45 PM, Steven Costiou  wrote:
> For example that works for me:
>
> |ast|
> ast := (MyClass >> #printOn:) ast.
> ast body: (MyClass >> #returnSelf) ast body.
> MyClass compile: ast newSource
>
> Le 2017-12-03 23:42, Steven Costiou a écrit :
>
> Hi,
>
> just after your modifications, from the compiled method try:
>
> ObjSkeletonMock compile: self ast newSource
>
> Maybe not the most elegant but it works.
>
>
>
> Steven.
>
> Le 2017-12-03 22:31, Stephane Ducasse a écrit :
>
> Hi
>
> to prepare some code for students I want to convert methods into a
> kind of method skeleton
> ie
>
> printOn: aStream
> "super nice comment"
> lk;lk;
> kl;;kl
> k;lkl;k
> ^ 42
>
> into
>
> printOn: aStream
> "super nice comment"
> ^ self
>
> any idea?
>
> In the past I know that we could access the method comment but I do
> not find how to access the method signature (selector + variables).
>
> So I'm trying at the AST level.
>
> ((ObjSkeletonMock >> #methodToSkeletonize2) ast body:
> (ObjSkeletonMock >> #returnSelf) ast body).
>
> But I do not get how I can recompile this.
>
> Stef
>
>
>
> --
> kloum.io
>
>
>
> --
> kloum.io

Re: [Pharo-users] Simplifying a File reference (Ben Coman)

[Alistair Grant]

On 4 December 2017 at 01:48, Ben Coman  wrote:
>
>
> On 4 December 2017 at 08:25, Richard A. O'Keefe  wrote:
>>
>>
>> Ben Coman  wrote:
>>>
>>> While 'canonicalize' obviously fits, it seems a bit exotic and a tongue
>>> twist at five syllables.
>>> I wonder if 'flatten' might also be suitable.  Is there some concept this
>>> wouldn't cover?

Just my personal preference, but I think canonicalize is better in
this case.  Flatten to me implies taking all the entries in a
collection and removing the structure.  In this case, we aren't
removing the structure completely, the order of the segments still has
meaning.


>> There are two distinct issues.
>> (1) Can this file name be put into a form that would have the
>> same reference as the original whatever the state of the
>> file system?  (That is, whatever the same of the file
>> system, the original name and the new form will reference
>> to the same thing or neither will refer to anything, as
>> long as I don't change directory.)
>>
>> For this, it _is_ safe to collapse // to / (except at the
>> beginning) and to elide "." entries, but because of
>> symbolic links it is *not* safe to elide ".." entries.
>>
>> (2) Give me an absolute path name that does not contain any
>> symbolic links and will refer to the same file as long
>> as no directories along the way are renamed or deleted.
>>
>
> Thanks for you input.  Thats a nice framework to consider this.
> Someone else will have to advise the intent of the method.
>
>
>>
>> There is no POSIX function to do (1).
>> The POSIX function that does (2) is realpath(2).
>> If the Smalltalk method is intended to have the same semantics
>> as the realpath() function, it should have the same name,
>> possibly spelled #realPath.

#canonicalize isn't intended to have the same semantics as realpath.
Like it's python and java equivalents, it explicitly ignores symbolic
links.

It should be possible to implement realpath, however the current
stat() / lstat() functionality is broken in Pharo.  I've submitted an
enhancement that fixes this, hopefully it will be merged in soon. :-)
See 
https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems-to-be-broken-on-Linux


Cheers,
Alistair



> btw, my personal preference where we echo another api is to use identical
> capitalization.
> I believe this reduces friction transferring knowledge between domains.
> Lucky for me Pharo at least partially follows that convention  e.g.
> `basename`...
> https://github.com/pharo-project/pharo/blob/development/src/FileSystem-Core/FileSystemDirectoryEntry.class.st#L75
>
>  cheers -ben
>
>> There is a Solaris function called resolvepath() which is subtly
>> different from realpath() and not generally available.

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

[horrido]

Speaking of which, one of my readers said he tried out Pharo recently and
found the documentation wanting. He was expecting a Getting Started guide at
the pharo.org website and couldn't find one. So he had to blunder around a
bit.

I told him he could've looked at "Chapter 2: A quick tour of Pharo" in the
*Pharo by Example 5* book, but he's right. There ought to be something
obvious at the pharo.org website that helps a newbie get Pharo up and
running, understand how to basically use the Pharo IDE, and write the
standard "Hello World" program.

I checked out squeak.org and found the same documentation issue! Why is
this???


Offray Vladimir Luna Cárdenas-2 wrote
> Documentation is going well. In fact the stuff that kept me away of
> Squeak, despite of its potential was the lack of documentation. "The
> artifact is the curriculum" was to powerful but too heavy. You need a
> way to understand how to deconstruct and navigate the artifact that is
> usually anchored with the culture you have (books and reading) instead
> of only launching inspectors os browsing the code. Grafoscopio is my
> attempt to fill that gap between the world of objects/simulations and
> the world of scripts/documents.
> 
> Cheers,
> 
> Offray





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Simplifying a File reference (Ben Coman)

[Ben Coman]

On 4 December 2017 at 08:25, Richard A. O'Keefe  wrote:

>
> Ben Coman  wrote:
>
>> While 'canonicalize' obviously fits, it seems a bit exotic and a tongue
>> twist at five syllables.
>> I wonder if 'flatten' might also be suitable.  Is there some concept this
>> wouldn't cover?
>>
>
> There are two distinct issues.
> (1) Can this file name be put into a form that would have the
> same reference as the original whatever the state of the
> file system?  (That is, whatever the same of the file
> system, the original name and the new form will reference
> to the same thing or neither will refer to anything, as
> long as I don't change directory.)
>
> For this, it _is_ safe to collapse // to / (except at the
> beginning) and to elide "." entries, but because of
> symbolic links it is *not* safe to elide ".." entries.
>
> (2) Give me an absolute path name that does not contain any
> symbolic links and will refer to the same file as long
> as no directories along the way are renamed or deleted.
>
>
Thanks for you input.  Thats a nice framework to consider this.
Someone else will have to advise the intent of the method.



> There is no POSIX function to do (1).
> The POSIX function that does (2) is realpath(2).
> If the Smalltalk method is intended to have the same semantics
> as the realpath() function, it should have the same name,
> possibly spelled #realPath.
>

btw, my personal preference where we echo another api is to use identical
capitalization.
I believe this reduces friction transferring knowledge between domains.
Lucky for me Pharo at least partially follows that convention  e.g.
`basename`...
https://github.com/pharo-project/pharo/blob/development/src/FileSystem-Core/FileSystemDirectoryEntry.class.st#L75

 cheers -ben

There is a Solaris function called resolvepath() which is subtly
> different from realpath() and not generally available.
>
>

Re: [Pharo-users] Simplifying a File reference (Ben Coman)

[Richard A. O'Keefe]

Ben Coman  wrote:

While 'canonicalize' obviously fits, it seems a bit exotic and a tongue
twist at five syllables.
I wonder if 'flatten' might also be suitable.  Is there some concept this
wouldn't cover?


There are two distinct issues.
(1) Can this file name be put into a form that would have the
same reference as the original whatever the state of the
file system?  (That is, whatever the same of the file
system, the original name and the new form will reference
to the same thing or neither will refer to anything, as
long as I don't change directory.)

For this, it _is_ safe to collapse // to / (except at the
beginning) and to elide "." entries, but because of
symbolic links it is *not* safe to elide ".." entries.

(2) Give me an absolute path name that does not contain any
symbolic links and will refer to the same file as long
as no directories along the way are renamed or deleted.

There is no POSIX function to do (1).
The POSIX function that does (2) is realpath(2).
If the Smalltalk method is intended to have the same semantics
as the realpath() function, it should have the same name,
possibly spelled #realPath.

There is a Solaris function called resolvepath() which is subtly
different from realpath() and not generally available.

Re: [Pharo-users] How to remove method body?

[Steven Costiou]

For example that works for me: 

|ast|
ast := (MyClass >> #printOn:) ast.
ast body: (MyClass >> #returnSelf) ast body.
MyClass compile: ast newSource 

Le 2017-12-03 23:42, Steven Costiou a écrit :

> Hi, 
> 
> just after your modifications, from the compiled method try: 
> 
> ObjSkeletonMock compile: self ast newSource 
> 
> Maybe not the most elegant but it works. 
> 
> Steven. 
> 
> Le 2017-12-03 22:31, Stephane Ducasse a écrit :
> 
>> Hi
>> 
>> to prepare some code for students I want to convert methods into a
>> kind of method skeleton
>> ie
>> 
>> printOn: aStream
>> "super nice comment"
>> lk;lk;
>> kl;;kl
>> k;lkl;k
>> ^ 42
>> 
>> into
>> 
>> printOn: aStream
>> "super nice comment"
>> ^ self
>> 
>> any idea?
>> 
>> In the past I know that we could access the method comment but I do
>> not find how to access the method signature (selector + variables).
>> 
>> So I'm trying at the AST level.
>> 
>> ((ObjSkeletonMock >> #methodToSkeletonize2) ast body:
>> (ObjSkeletonMock >> #returnSelf) ast body).
>> 
>> But I do not get how I can recompile this.
>> 
>> Stef
> 
> -- 
> kloum.io

-- 
kloum.io 

Re: [Pharo-users] How to remove method body?

[Steven Costiou]

Hi, 

just after your modifications, from the compiled method try: 

ObjSkeletonMock compile: self ast newSource 

Maybe not the most elegant but it works. 

Steven. 

Le 2017-12-03 22:31, Stephane Ducasse a écrit :

> Hi
> 
> to prepare some code for students I want to convert methods into a
> kind of method skeleton
> ie
> 
> printOn: aStream
> "super nice comment"
> lk;lk;
> kl;;kl
> k;lkl;k
> ^ 42
> 
> into
> 
> printOn: aStream
> "super nice comment"
> ^ self
> 
> any idea?
> 
> In the past I know that we could access the method comment but I do
> not find how to access the method signature (selector + variables).
> 
> So I'm trying at the AST level.
> 
> ((ObjSkeletonMock >> #methodToSkeletonize2) ast body:
> (ObjSkeletonMock >> #returnSelf) ast body).
> 
> But I do not get how I can recompile this.
> 
> Stef

-- 
kloum.io 

[Pharo-users] How to remove method body?

[Stephane Ducasse]

Hi

to prepare some code for students I want to convert methods into a
kind of method skeleton
ie

printOn: aStream
"super nice comment"
lk;lk;
kl;;kl
k;lkl;k
^ 42

into

printOn: aStream
"super nice comment"
^ self

any idea?

In the past I know that we could access the method comment but I do
not find how to access the method signature (selector + variables).

So I'm trying at the AST level.

((ObjSkeletonMock >> #methodToSkeletonize2) ast body:
(ObjSkeletonMock >> #returnSelf) ast body).

But I do not get how I can recompile this.

Stef

Re: [Pharo-users] PharoThings - Metacello installation broken

[Denis Kudriashov]

Thank's for report.
I fixed it. Try again.

I will set up travis to cover such problems. I never tested it on fresh
computer

2017-12-03 16:48 GMT+01:00 bachitoph :

> Hi,
> I'm just trying https://github.com/pharo-iot/PharoThings. But if
> installing
> the client side as suggested below.
>
> Install the client part of PharoThings in the development (client) Pharo
> image:
>
> Metacello new
>   baseline: 'PharoThings';
>   repository: 'github://pharo-iot/PharoThings/src';
>   load: 'RemoteDev'
>
> After some loading I get the Metacello message
>
> github--pharoiotFirmatav01x157812618139788200831786773995104653406.zip
> does
> not exist.
>
> I tried this under Windows10 with fresh loaded Pharo 6.1 from
> www.pharo.org.
>
> any hints?
>
> thanks
> cjb
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>

Re: [Pharo-users] Glorp v130 call for testing

[Alistair Grant]

On 1 December 2017 at 13:46, Alistair Grant  wrote:
> Hi Everyone,
>
> There haven't been any complaints about the merged version, and Glorp
> fails to load #development on Pharo 7, so I'm planning to update
> ConfigurationOfGlorp to:
>
> - Work on Pharo7 when given the #development symbolic version
> - Make Glorp-AlistairGrant.130 the stable version - up from
> Glorp-HerbyVojcik.127.
>
> If I don't hear any objections in the next couple of days I'll make the 
> change.

I haven't heard any objections, so... ConfigurationOfGlorp-AlistairGrant.63:

- Promote Glorp-AlistairGrant.130 to stable
- Add Pharo 7 support to #development symbolic version

Cheers,
Alistair

[Pharo-users] PharoThings - Metacello installation broken

[bachitoph]

Hi,
I'm just trying https://github.com/pharo-iot/PharoThings. But if installing
the client side as suggested below.

Install the client part of PharoThings in the development (client) Pharo
image:

Metacello new
  baseline: 'PharoThings';
  repository: 'github://pharo-iot/PharoThings/src';
  load: 'RemoteDev'

After some loading I get the Metacello message

github--pharoiotFirmatav01x157812618139788200831786773995104653406.zip does
not exist.

I tried this under Windows10 with fresh loaded Pharo 6.1 from www.pharo.org.

any hints?

thanks
cjb



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html