[Pharo-project] DocTest

[Benjamin]

Hi guys,

I am attending a python lecture and discovered DocTest[1], and I was wondering 
if such a tool exists for Pharo ? :)


Ben

[1]http://docs.python.org/2/library/doctest.html

Re: [Pharo-project] [Ann] New version of Mocketry

[Esteban Lorenzano]

Thanks Denis :)

On Jan 20, 2013, at 7:08 PM, Denis Kudriashov  wrote:

> Hello.
> 
> I upload new version of Mocketry 2.1 to smalltalkhub 
> http://www.smalltalkhub.com/#!/~dionisiy/Mocketry .
> 
> Changes:
> 
> 1) All code now migrated to smalltalkhub repository. New configuration with 
> version 2.1 implemented accordingly.
> 2) State specs extracted to separate project "StateSpecs" with separate 
> configuration. This project contains all object state specifications and 
> validation stuff. Mocketry depends on it and only implements behaviour specs 
> and mock objects. StateSpecs can be used in different projects. I use it in 
> Presenty to describe data fields validness.
> 3) Main new feature is stub behaviour. You can teach mock for stubs with:
> mock stub someMessage willReturn: 'result'
> And then mock can receive #someMessage everywhere anytimes. So you don't need 
> scenario block if you only need stubs behaviour.
> 4) Few state specs like
> dictionary should include: item at: #key
> 
> It will be cool if Mocketry become part of Pharo tools. What I can do for 
> this?
> Mock objects to me is main tool to design and implement flexible object 
> systems. And Mocketry simplifies mock objects technique very much.
> 
> Best regards,
> Denis
> 
> 

Re: [Pharo-project] zero conf build

[Camillo Bruni]

which script did you use? so I can check locally.


On 2013-01-21, at 08:24, Tudor Girba  wrote:
> Hi,
> 
> I am looking to setup a Moose job based on zero conf.
> 
> However, when I execute the vm.sh on Ubuntu I get an error:
> CogVM: /lib32/libc.so.6: version `GLIBC_2.15' not found
> 
> I already installed lib32. What else should I do?
> 
> Cheers,
> Doru
> 
> 
> On Oct 23, 2012, at 7:11 AM, Sven Van Caekenberghe  wrote:
> 
>> Very cool !
>> 
>> Thanks a lot for all the work.
>> 
>> On 23 Oct 2012, at 00:28, Camillo Bruni  wrote:
>> 
>>> I finally managed to create a zero conf pharo image build setup:
>>> 
>>> # 
>>> ===
>>> curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh
>>> ./vm.sh Pharo.image save $JOB_NAME
>>> 
>>> REPO=http://smalltalkhub.com/mc/dh83/nabujito/main
>>> ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfNabujito 
>>> --install=development
>>> ./vm.sh $JOB_NAME.image test --junit-xml-output Nabujito
>>> 
>>> zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes
>>> # 
>>> ===
>>> 
>>> ./ciPharo20Cog.sh --help
>>> 
>>> This is an entry point script for any Pharo image CI
>>> This script will download the latest Pharo 2.0 image and the latest VM
>>> 
>>> Result in the current directory:
>>>  vm   directory containing the VM
>>>  vm.shscript forwarding to the VM inside vm/
>>>  Pharo.image  The latest pharo image
>>>  Pharo.changesThe corresponding pharo changes"
>>> 
>>> # 
>>> ===
>>> 
>>> have fun!
>> 
>> 
> 
> --
> www.tudorgirba.com
> 
> "Problem solving should be focused on describing
> the problem in a way that makes the solution obvious."
> 
> 
> 
> 
> 

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

[Mariano Martinez Peck]

On Sat, Jan 19, 2013 at 12:08 PM, Mariano Martinez Peck <
marianop...@gmail.com> wrote:

>
>
> On Sat, Jan 19, 2013 at 10:40 AM, Ciprian Teodorov <
> ciprian.teodo...@gmail.com> wrote:
>
>> Hi Mariano,
>>
>> on MacOS 10.6.8 doing  
>> ./CogVM-release-noflash-noArgs.app/Contents/MacOS/CogVM
>> Pier3.image does not work, I get Illegal instruction...
>> the same with ./CogVM-release-noflash-noArgs.app/Contents/MacOS/CogVM
>> --headless Pier3.image
>>
>> if i try using open CogVM-release-noflash-noArgs.app Pier3.image, it
>> works but It's not headless, however when looking in the info.plist the key
>> you have mentioned is there
>> LSBackgroundOnly
>> 
>>
>>
> Well, this one is weird ;)  I think the problem is (as Mark pointed out)
> the "open". When you do:
>
> open CogVM-release-noflash-noArgs.app Pier3.image
>
> I will (I think) do two things:
> - open the CogVM-release-noflash-noArgs.app (which will popup the window
> to choose an image)
> - open the Pier3.image with the default app associated (that would be the
> same as double clicking the .image from the finder)
>
> So, I think that what you need is to add the "-a":
>
> open -a CogVM-release-noflash-noArgs.app Pier3.image
>
> In this case, you should at least get the same behavior as:
>
>  ./CogVM-release-noflash-noArgs.app/Contents/MacOS/CogVM Pier3.image
>
> that is, a ilegal instruction. Is it like this?
>
> Now...why the ilegal instruction?? I don't know. I will check. I could be
> maybe what I said that I compiled with LLVM GCC.
> We should compile this VM with GNU GCC...but so far I couldn't in 10.8.2
> :(
>
>
Well, I have compiled a normal VM (without my headless changes) with LLVM
GCC.
Now, can you try this VM (CogVM-standard) please? If we get Ilegal
Instruction, then it is the compiler. If we don't, and it works, then it is
something related with my changes.
https://www.dropbox.com/s/kpqnfycjpe76fo1/CogVM-standard.zip


Thanks,





> Thanks for the testing to everybody!!!
>
>
>>
>> On Sat, Jan 19, 2013 at 2:26 PM, Mariano Martinez Peck <
>> marianop...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Jan 19, 2013 at 7:24 AM, Stephan Eggermont wrote:
>>>
 This doesn't work


  open CogVM-release-noflash-noArgs.app Pier3.image &


>>> Which OSX version are you using?
>>>
>>>
>>>

 Jan 19 11:20:51 Stephan-Eggermonts-iMac
 [0x0-0x2f92f9].org.seaside-project[36832]: This interpreter (vers. 6502)
 cannot read image file (vers. 6505).
 Jan 19 11:20:51 Stephan-Eggermonts-iMac
 [0x0-0x2f92f9].org.seaside-project[36832]: Press CR to quit...
 Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Failed to
 create CSSymbolicatorRef for launchd
 Jan 19 11:20:52 Stephan-Eggermonts-iMac
 com.apple.launchd.peruser.501[207]
 ([0x0-0x2fa2fa].org.squeakfoundation.Squeak[36835]): Job appears to have
 crashed: Segmentation fault
 Jan 19 11:20:52 Stephan-Eggermonts-iMac ReportCrash[36836]: Saved crash
 report for launchd[36835] version ??? (???) to
 /Users/stephan/Library/Logs/DiagnosticReports/launchd_2013-01-19-112052_Stephan-Eggermonts-iMac.crash

>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>>
>>
>> --
>> Dr. Ciprian TEODOROV
>> Ingénieur Développement CAO
>>
>> tél : 06 08 54 73 48
>> mail : ciprian.teodo...@gmail.com
>> www.teodorov.ro
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

[Mariano Martinez Peck]

On Sat, Jan 19, 2013 at 1:08 PM, Sean P. DeNigris wrote:

> Mariano Martinez Peck wrote
> > thanks Square [i] International ;
> > ... headless support will be included in the official Pharo
> > VM and will be, therefore, accessible to everybody.
>
> Yes, thank you, thank you!! I've been using Pharo for Jenkins build
> scripts,
> and it was really disruptive to see the image pop up every time a job
> started.
>
> As to the flag limitation, I think for now I'll have two copies of the VM -
> a headful one, which will be the default on my Mac, and one with the
> headless flag set, that gets explicitly launched by Jenkins... not perfect,
> but a HUGE step!!
>

Yes, that's the easiest way.
I spent *a lot* of time trying to find another way, but they all failed.
There is one possibility that should work but it is too hacky for me:
very at the beginning of the VM (before starting Cocoa) read the arguments.
If "-headless" is present, then programmatically set/write the flag in the
Info.plist. If it it not, do nothing (or set it to false).  But modifying
the file on startup looks hacky to me. I prefer the user to manually set
it.


> Cheers,
> Sean
>
>
>
> --
> View this message in context:
> http://forum.world.st/ANN-Headless-support-for-Cog-Cocoa-VM-tp4664137p4664212.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>


-- 
Mariano
http://marianopeck.wordpress.com

[Pharo-project] Fonts in Pharo By Example

[Sean P. DeNigris]

It would be great to have a section in PBE2 about fonts. I find them very
confusing - TrueType, FreeType, Logical, etc. Understanding how they're
handled in Pharo requires background knowledge, and an overview and a few
specific examples could really do some good.

Cheers,
Sean



--
View this message in context: 
http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

[Pharo-project] is the list working?

[Tudor Girba]

Hi,

I did not receive any mails today from the pharo-project mailing list
(21.01.2013). Is it still working?

Cheers,
Doru


-- 
www.tudorgirba.com

"Every thing has its own flow"

[Pharo-project] Closing unresolved issues

[Sean P. DeNigris]

For example...
 Issue 5656: Large fonts make tools slow
 http://code.google.com/p/pharo/issues/detail?id=5656

This issue has not been resolved, but the issue was closed, leading to this
experience...
- I just upgraded a project to 2.0
- I notice that the UI is very slow - a simple Spec dialog window with a few
text fields and buttons takes ~4 seconds to open
- I check the issue tracker because I remember I reported the bug already,
but I don't find it in the open issues
- I waste time because I think it must be something else
- I finally expand my search through the issues and find my report was
closed as invalid

I'm not saying that this is wrong, just that I don't understand and want to
share another perspective and come to the best solution...  What benefit are
we getting from closing these that is significant enough to justify this
kind of experience (I'm sure I'm not the only one).

Cheers,
Sean



--
View this message in context: 
http://forum.world.st/Closing-unresolved-issues-tp4664420.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

[Pharo-project] [update 2.0] #20481

[Marcus Denker]

20481
-

Issue 7275: Sanitize String with/without selectors
http://code.google.com/p/pharo/issues/detail?id=7275

Issue 7288: Clean methods are just do super send
http://code.google.com/p/pharo/issues/detail?id=7288


Diff information:
http://ss3.gemstone.com/ss/Pharo20/Zinc-HTTP-MarcusDenker.338.diff
http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1013.diff
http://ss3.gemstone.com/ss/Pharo20/NOCompletion-MarcusDenker.32.diff
http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1326.diff
http://ss3.gemstone.com/ss/Pharo20/Manifest-CriticBrowser-MarcusDenker.38.diff
http://ss3.gemstone.com/ss/Pharo20/Graphics-Fonts-MarcusDenker.67.diff
http://ss3.gemstone.com/ss/Pharo20/CollectionsTests-MarcusDenker.583.diff
http://ss3.gemstone.com/ss/Pharo20/Collections-Strings-MarcusDenker.238.diff

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

[H. Hirzel]

Dave

I wonder why you can't check for

Smalltalk at: #OSPlatform

and if that exists go for
OSPlatform osVersion

Neither Squeak nor Cuis do have an OSPlatform class.

Then you go for
Smalltalk os version

Am I missing something here?

--Hannes

On 1/21/13, David T. Lewis  wrote:
> Why is OSPlatform class>>osVersion deprecated but OSPlatform
> class>>platformName
> is not?
>
> My suggestion would be to comment #osVersion as being a synonym for
> #version,
> but do not deprecate it. That would enable use of "Smalltalk os version",
> and
> it would also support "OSPlatform osVersion", both of which make logical
> sense.
> It would also maintain support for external packages that rely on
> #osVersion
> to figure out platform differences.
>
> The reason that I am asking is that I am trying to find a way to make
> OSProcess class>>osVersion work on Pharo 2.0, Pharo1.x, and the various
> versions of Squeak and Cuis. I quite honestly cannot figure out any way to
> add Pharo 2.0 without breaking one more more of the other supported images.
> If OSPlatform class>>osVersion did not raise a deprecation warning, then
> I could make it work.
>
> Thanks,
> Dave
>
>
>

Re: [Pharo-project] [Ann] New version of Mocketry

[Stéphane Ducasse]

On Jan 20, 2013, at 3:08 PM, Denis Kudriashov wrote:

> Hello.
> 
> I upload new version of Mocketry 2.1 to smalltalkhub 
> http://www.smalltalkhub.com/#!/~dionisiy/Mocketry .
> 
> Changes:
> 
> 1) All code now migrated to smalltalkhub repository. New configuration with 
> version 2.1 implemented accordingly.
> 2) State specs extracted to separate project "StateSpecs" with separate 
> configuration. This project contains all object state specifications and 
> validation stuff. Mocketry depends on it and only implements behaviour specs 
> and mock objects. StateSpecs can be used in different projects. I use it in 
> Presenty to describe data fields validness.
> 3) Main new feature is stub behaviour. You can teach mock for stubs with:
> mock stub someMessage willReturn: 'result'
> And then mock can receive #someMessage everywhere anytimes. So you don't need 
> scenario block if you only need stubs behaviour.
> 4) Few state specs like
> dictionary should include: item at: #key
> 
> It will be cool if Mocketry become part of Pharo tools. What I can do for 
> this?

ConfigurationOfMocketry
Tests
SmallLint rules applied.

Ideally we want to manage pharo as a list of configuration + a main one.
Then people should be able to load in one click "certified" package via their 
configuration.

Then if people write a lof of mockertry based tests for the central part of the 
system it can sit side by side to SUnit.
But in general the idea is to have a modular system so first steps are above.


> Mock objects to me is main tool to design and implement flexible object 
> systems. And Mocketry simplifies mock objects technique very much.
> 
> Best regards,
> Denis
> 
> 

Re: [Pharo-project] where can I find the latest athens?

[Stéphane Ducasse]

yes but I could not find it and I looked around.

On Jan 20, 2013, at 7:30 PM, Camillo Bruni wrote:

> You should not even have to ask for it ;)
> 
> https://ci.inria.fr/rmod/job/Athens/
> 
> 
> On 2013-01-20, at 16:00, Stéphane Ducasse  wrote:
> 
>> Because I want to try boids.
>> 
>> Stef
>> 
> 
> 

[Pharo-project] [Issue Tracker] Status

[Marcus Denker]

Overall open issues:
http://code.google.com/p/pharo/issues/list?can=2

Issues tagged 2.0:

http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D2.0

It would be nice if everyone would check the issues that she/he is involved with
and answer the question: 

"What needs to be done as the next step to move this issue forward to a state 
where we can close the entry?"

If there are issues where *You* where supposed to do something for the last
6 Month but it turned out to be so non-important that you never did, please
consider that maybe the report itself is not important enough to stay open.

Marcus

[Pharo-project] [update 2.0] #20482

[Marcus Denker]

20482
-

Issue 7261: Improve PharoUser>>#retrieveGravatarFromMail:size: ZnClient 
usage
http://code.google.com/p/pharo/issues/detail?id=7261

Issue 7267: Update Pharo License String to 2013
http://code.google.com/p/pharo/issues/detail?id=7267

Diff information:
http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.761.diff
http://ss3.gemstone.com/ss/Pharo20/KeyChain-MarcusDenker.27.diff

Re: [Pharo-project] What are the messages where we should always have a super send?

[Jan Vrany]

Hi,

On 19/01/13 10:16, Stéphane Ducasse wrote:

Hi jan

do you have an example of such tagging?


Look at

RBTranslateLiteralsInMenusRule class>>tagsBasic,
RBNilOrEmptyCollectionReplaceRule,
RBMethodSourceContainsLinefeedRule,
RBTempsReadBeforeWrittenRile
RBLawOfDemeterRule
RBContainsNamespaceIdentifiersRule

at

http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/

Some comment on tagging

http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RBLintRule.st?revision=1.9&view=markup


Could you please give me a pointer where newest Lint for Pharo
lives?


Cheers, Jan




Right now we are also thinking that we want three kinds of rules
- 1 whose result is either zero because there is no problem or zero 
because we flag the false positives
- 2 more fuzzy one where we should have flase positive defined per 
package
- 3 more statistical rules (long methods, large number of instance 
variables)

We are checking how we can find decent threshold values not generating 
thousands of warnings and
also if we want to embed false positives for them too. May be they are just 
good for trend analysis and
when you want to spot ugly code but you do not care to have them under your 
nose systematically.

For the rules I'm also changing the implementation to make sure that we can 
customized the list of selectors, thresholds ….
without having to recompile a method. This way people will be able to use their 
own conventions.

Stef

On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote:


Hi Stef,

while massaging SmallLint rules, you should also have look at
Smalltalk/X version of SmallLint [1] as we have ported
Pharo version and improved some rules. I have also added
a tagging system. That's useful for some rules are only
good if you want to ensure portable code, some are simply
broken and some stupid, etc. Having them properly classified
would help us all.

Tell me once you finish your ride, I'll merge changes back :-)

Jan

[1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/

to checkout issue:

cvs -d :pserver:c...@cvs.smalltalk-x.de:/cvs/stx co 
stx/goodies/refactoryBrowser/lint/


On 18/01/13 17:06, Stéphane Ducasse wrote:

Hi

While looking at SmallLint rule, I saw a rule that ensures that a given method 
always performs a
super send.

Here is the current list:

^#(#release #postCopy  #preBuildWith: #postOpenWith: 
#noticeOfWindowClose: #initialize postBuildWith:)


and I'm cleaning the list because there are VW elements such as postBuildWith:
but do we have some other to add?

Stef

Re: [Pharo-project] is the list working?

[Marcus Denker]

I think not. I will write a mail to support...

On Mon, Jan 21, 2013 at 5:17 PM, Tudor Girba  wrote:
> Hi,
>
> I did not receive any mails today from the pharo-project mailing list
> (21.01.2013). Is it still working?
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"



-- 
--
Marcus Denker  --  den...@acm.org
http://www.marcusdenker.de

[Pharo-project] Object>>#name

[Sven Van Caekenberghe]

Hi,

Many people have hit the fact that Object implements #name, which then seems to 
conflict with some other class where one would really like to use name as an 
instance variable and thus accessor.

Turns out that it seems that Object>>#name is actually not used (anymore).

I just put a halt in it and tried a couple of tools and everything seems to 
work just fine.

The comment talks about Inspector use, but there is #defaultLabelForInspector 
for that.

It is a small thing, but it confuses everybody for no good reason,

Any comments ?

Sven

PS: it was also in the testing procotol ;-)

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill

Re: [Pharo-project] What are the messages where we should always have a super send?

[Stéphane Ducasse]

> Yes, #setUp and #tearDown

Really.
Ok I was not aware of it.
Good idea.

Stef
> For #initialize, having a super may not be that necessary if you working on 
> the class side.
> 
> Alexandre
> 
> 
> On Jan 18, 2013, at 12:06 PM, Stéphane Ducasse  
> wrote:
> 
>> Hi 
>> 
>> While looking at SmallLint rule, I saw a rule that ensures that a given 
>> method always performs a
>> super send.
>> 
>> Here is the current list: 
>> 
>>  ^#(#release #postCopy  #preBuildWith: #postOpenWith: 
>> #noticeOfWindowClose: #initialize postBuildWith:)
>> 
>> 
>> and I'm cleaning the list because there are VW elements such as 
>> postBuildWith:
>> but do we have some other to add?
>> 
>> Stef
>> 
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

[Pharo-project] ping

[Camillo Bruni]

[Pharo-project] Fwd: [Moose-dev] ZnUrl, Encoding

[H. Hirzel]

I assume this question is better placed here 

I am interested in the answer as well.

--Hannes

-- Forwarded message --
From: Dennis Schenk 
Date: Tue, 22 Jan 2013 14:00:06 +0100
Subject: [Moose-dev] ZnUrl, Encoding
To: Moose-related development 

Hi all,

I stumpled upon a problem with encoding of URLs in Pharo.

I am using the Google Geocoding API. For example I want to get the result
of:
http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Curaçao&sensor=false&language=en

When one enters this in a Browser a correct JSON response is returned.

If I do the following:

*(Url absoluteFromText: '
http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Curaçao&sensor=false&language=en')
retrieveContents contents.*

I get an error back grom Google.

When digging through the code I found that in ZnHTTPSocketFacade the
following happens:

*'
http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Curaçao&sensor=false&language=en'
asZnUrl *

And the result of this is:

http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Cura%C3%A7ao&sensor=false&language=en
*
*
Which Google does not know how to handle and then returns an error.

Does anyone have an idea how I could get contents from a URL which has
special chars like '*ç'?*

Or is there a way to convert all special chars to to their 'normal'
counterparts, like *ç -> c?*
*
*
Cheers,
Dennis

[Pharo-project] a test :) yet another one.

[Stéphane Ducasse]

Re: [Pharo-project] is the list working?

[Benjamin]

I received your mail so I guess :)


Ben

On Jan 21, 2013, at 5:17 PM, Tudor Girba wrote:

> Hi,
> 
> I did not receive any mails today from the pharo-project mailing list 
> (21.01.2013). Is it still working?
> 
> Cheers,
> Doru
> 
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"

Re: [Pharo-project] Closing unresolved issues

[Sven Van Caekenberghe]

+1

On 21 Jan 2013, at 17:35, "Sean P. DeNigris"  wrote:

> For example...
> Issue 5656: Large fonts make tools slow
> http://code.google.com/p/pharo/issues/detail?id=5656
> 
> This issue has not been resolved, but the issue was closed, leading to this
> experience...
> - I just upgraded a project to 2.0
> - I notice that the UI is very slow - a simple Spec dialog window with a few
> text fields and buttons takes ~4 seconds to open
> - I check the issue tracker because I remember I reported the bug already,
> but I don't find it in the open issues
> - I waste time because I think it must be something else
> - I finally expand my search through the issues and find my report was
> closed as invalid
> 
> I'm not saying that this is wrong, just that I don't understand and want to
> share another perspective and come to the best solution...  What benefit are
> we getting from closing these that is significant enough to justify this
> kind of experience (I'm sure I'm not the only one).
> 
> Cheers,
> Sean

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

[Esteban Lorenzano]

yeah, I declare my self guilty for having that incredibly ugly idea... :)

On Jan 21, 2013, at 3:35 PM, Mariano Martinez Peck  
wrote:

> 
> 
> On Sat, Jan 19, 2013 at 1:08 PM, Sean P. DeNigris  
> wrote:
> Mariano Martinez Peck wrote
> > thanks Square [i] International ;
> > ... headless support will be included in the official Pharo
> > VM and will be, therefore, accessible to everybody.
> 
> Yes, thank you, thank you!! I've been using Pharo for Jenkins build scripts,
> and it was really disruptive to see the image pop up every time a job
> started.
> 
> As to the flag limitation, I think for now I'll have two copies of the VM -
> a headful one, which will be the default on my Mac, and one with the
> headless flag set, that gets explicitly launched by Jenkins... not perfect,
> but a HUGE step!!
> 
> Yes, that's the easiest way. 
> I spent *a lot* of time trying to find another way, but they all failed. 
> There is one possibility that should work but it is too hacky for me:
> very at the beginning of the VM (before starting Cocoa) read the arguments. 
> If "-headless" is present, then programmatically set/write the flag in the 
> Info.plist. If it it not, do nothing (or set it to false).  But modifying the 
> file on startup looks hacky to me. I prefer the user to manually set it. 
> 
> 
> Cheers,
> Sean
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/ANN-Headless-support-for-Cog-Cocoa-VM-tp4664137p4664212.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

Re: [Pharo-project] a test :) yet another one.

[Marcus Denker]

Hi,

Yes, mailing lists where down and I on the train, so the ticket to supper
was only send yesterday after office hours… and today I spend some
effort convincing the admins that no, it's not my mail client that is
wrong configured…

Marcus

On Jan 22, 2013, at 5:43 PM, Stéphane Ducasse  wrote:

> 
> 

Re: [Pharo-project] zero conf build

[Tudor Girba]

For example:

curl http://pharo.gforge.inria.fr/ci/script/ciPharo20PharoVM.sh | sh
./vm.sh

or:

curl http://pharo.gforge.inria.fr/ci/script/ciPharo20CogVM.sh | bash.
./vm.sh

Cheers,
Doru



On Mon, Jan 21, 2013 at 2:28 PM, Camillo Bruni wrote:

> which script did you use? so I can check locally.
>
>
> On 2013-01-21, at 08:24, Tudor Girba  wrote:
> > Hi,
> >
> > I am looking to setup a Moose job based on zero conf.
> >
> > However, when I execute the vm.sh on Ubuntu I get an error:
> > CogVM: /lib32/libc.so.6: version `GLIBC_2.15' not found
> >
> > I already installed lib32. What else should I do?
> >
> > Cheers,
> > Doru
> >
> >
> > On Oct 23, 2012, at 7:11 AM, Sven Van Caekenberghe  wrote:
> >
> >> Very cool !
> >>
> >> Thanks a lot for all the work.
> >>
> >> On 23 Oct 2012, at 00:28, Camillo Bruni  wrote:
> >>
> >>> I finally managed to create a zero conf pharo image build setup:
> >>>
> >>> #
> ===
> >>> curl http://pharo.gforge.inria.fr/ci/ciPharo20Cog.sh | sh
> >>> ./vm.sh Pharo.image save $JOB_NAME
> >>>
> >>> REPO=http://smalltalkhub.com/mc/dh83/nabujito/main
> >>> ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfNabujito
> --install=development
> >>> ./vm.sh $JOB_NAME.image test --junit-xml-output Nabujito
> >>>
> >>> zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes
> >>> #
> ===
> >>>
> >>> ./ciPharo20Cog.sh --help
> >>>
> >>> This is an entry point script for any Pharo image CI
> >>> This script will download the latest Pharo 2.0 image and the latest VM
> >>>
> >>> Result in the current directory:
> >>>  vm   directory containing the VM
> >>>  vm.shscript forwarding to the VM inside vm/
> >>>  Pharo.image  The latest pharo image
> >>>  Pharo.changesThe corresponding pharo changes"
> >>>
> >>> #
> ===
> >>>
> >>> have fun!
> >>
> >>
> >
> > --
> > www.tudorgirba.com
> >
> > "Problem solving should be focused on describing
> > the problem in a way that makes the solution obvious."
> >
> >
> >
> >
> >
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

[Sean P. DeNigris]

David T. Lewis wrote
> I am trying to find a way to make OSProcess... work on Pharo 2.0,
> Pharo1.x, and the various versions of Squeak and Cuis

I've been thinking a lot about keeping OSP working well on all our favorite
St platforms. Metacello was designed specifically to address this type of
problem, which I'm sure will multiply as squeak and pharo evolve. I wonder
if MetaC works with Cuis... If not, and for older versions of Squeak/Pharo,
there could be a Gofer/Installer script like the one for FFI, or - easier
for users but maybe a little more work - the multiple packages could be
loaded in each supported platform and re-commited as a single
platform-specific package e.g. OSProcessSqueak44, OSProcessPharo20; so
development would be done w. MetaC, and users can simply download one
package. This would also free us from the branching that currently exists to
figure out which system we're on. Are you open to committing to the
multiple-package path going forward and relying on MetaC to manage these
incompatibilities?

Sean



--
View this message in context: 
http://forum.world.st/Must-OSPlatform-class-osVersion-be-deprecated-tp4664343p4664592.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] Object>>#name

[Mariano Martinez Peck]

Hi Sven. Yes, as far as I remember, Object>>name was safe to remove. Not
likewise Class>>name but ok, it is less likely final users will need class
side #name.
So +1 to removing instance side #name.


On Mon, Jan 21, 2013 at 3:43 PM, Sven Van Caekenberghe  wrote:

> Hi,
>
> Many people have hit the fact that Object implements #name, which then
> seems to conflict with some other class where one would really like to use
> name as an instance variable and thus accessor.
>
> Turns out that it seems that Object>>#name is actually not used (anymore).
>
> I just put a halt in it and tried a couple of tools and everything seems
> to work just fine.
>
> The comment talks about Inspector use, but there is
> #defaultLabelForInspector for that.
>
> It is a small thing, but it confuses everybody for no good reason,
>
> Any comments ?
>
> Sven
>
> PS: it was also in the testing procotol ;-)
>
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-project] Object>>#name

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> Many people have hit the fact that Object implements #name, which then
> seems to conflict with some other class where one would really like to use
> name as an instance variable and thus accessor.

Yes, I've been bitten by this a few times. When developing through the
debugger, it's confusing when the thing fails silently instead of prompting
to create the method.


Sven Van Caekenberghe-2 wrote
> Turns out that it seems that Object>>#name is actually not used (anymore).

There are lots of senders... I guess they're sending Class>>#name or another
message. I  say ditch it, but wait until 3.0...



--
View this message in context: 
http://forum.world.st/Object-name-tp4664573p4664583.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

[Mariano Martinez Peck]

On Tue, Jan 22, 2013 at 1:19 PM, Esteban Lorenzano wrote:

> yeah, I declare my self guilty for having that incredibly ugly idea... :)
>
>
heheheheh :)
As you see (and I thanked in the email) Esteban has been helping me here.
And then he will merge and integrate :)


> On Jan 21, 2013, at 3:35 PM, Mariano Martinez Peck 
> wrote:
>
>
>
> On Sat, Jan 19, 2013 at 1:08 PM, Sean P. DeNigris 
> wrote:
>
>> Mariano Martinez Peck wrote
>> > thanks Square [i] International ;
>> > ... headless support will be included in the official Pharo
>> > VM and will be, therefore, accessible to everybody.
>>
>> Yes, thank you, thank you!! I've been using Pharo for Jenkins build
>> scripts,
>> and it was really disruptive to see the image pop up every time a job
>> started.
>>
>> As to the flag limitation, I think for now I'll have two copies of the VM
>> -
>> a headful one, which will be the default on my Mac, and one with the
>> headless flag set, that gets explicitly launched by Jenkins... not
>> perfect,
>> but a HUGE step!!
>>
>
> Yes, that's the easiest way.
> I spent *a lot* of time trying to find another way, but they all failed.
> There is one possibility that should work but it is too hacky for me:
> very at the beginning of the VM (before starting Cocoa) read the
> arguments. If "-headless" is present, then programmatically set/write the
> flag in the Info.plist. If it it not, do nothing (or set it to false).  But
> modifying the file on startup looks hacky to me. I prefer the user to
> manually set it.
>
>
>> Cheers,
>> Sean
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/ANN-Headless-support-for-Cog-Cocoa-VM-tp4664137p4664212.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-project] What are the messages where we should always have a super send?

[Stéphane Ducasse]

On Jan 22, 2013, at 7:19 AM, Jan Vrany wrote:

> Hi,
> 
> On 19/01/13 10:16, Stéphane Ducasse wrote:
>> Hi jan
>> 
>> do you have an example of such tagging?
> 
> Look at
> 
> RBTranslateLiteralsInMenusRule class>>tagsBasic,
> RBNilOrEmptyCollectionReplaceRule,
> RBMethodSourceContainsLinefeedRule,
> RBTempsReadBeforeWrittenRile
> RBLawOfDemeterRule
> RBContainsNamespaceIdentifiersRule
> 
> at
> 
> http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/
> 
> Some comment on tagging
> 
> http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RBLintRule.st?revision=1.9&view=markup


Ok It is a good idea.
What is the license of the changes you did?
And sorry but we do not want to have author in comment for the moment :)

> Could you please give me a pointer where newest Lint for Pharo
> lives?

For now it lives in Pharo20.
Once we migrate for real to smalltalkHub I want to have subprojects for RB, 
SmallLint.

We tried for  while to have none disruptive changes by putting changes as 
extensions of code critics but 
it does not work for cleaning the rules.


Stef

> 
> 
> Cheers, Jan
> 
> 
> 
>> Right now we are also thinking that we want three kinds of rules
>>  - 1 whose result is either zero because there is no problem or zero 
>> because we flag the false positives
>>  - 2 more fuzzy one where we should have flase positive defined per 
>> package
>>  - 3 more statistical rules (long methods, large number of instance 
>> variables)
>> 
>> We are checking how we can find decent threshold values not generating 
>> thousands of warnings and
>> also if we want to embed false positives for them too. May be they are just 
>> good for trend analysis and
>> when you want to spot ugly code but you do not care to have them under your 
>> nose systematically.
>> 
>> For the rules I'm also changing the implementation to make sure that we can 
>> customized the list of selectors, thresholds ….
>> without having to recompile a method. This way people will be able to use 
>> their own conventions.
>> 
>> Stef
>> 
>> On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote:
>> 
>>> Hi Stef,
>>> 
>>> while massaging SmallLint rules, you should also have look at
>>> Smalltalk/X version of SmallLint [1] as we have ported
>>> Pharo version and improved some rules. I have also added
>>> a tagging system. That's useful for some rules are only
>>> good if you want to ensure portable code, some are simply
>>> broken and some stupid, etc. Having them properly classified
>>> would help us all.
>>> 
>>> Tell me once you finish your ride, I'll merge changes back :-)
>>> 
>>> Jan
>>> 
>>> [1] 
>>> http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/
>>> 
>>> to checkout issue:
>>> 
>>> cvs -d :pserver:c...@cvs.smalltalk-x.de:/cvs/stx co 
>>> stx/goodies/refactoryBrowser/lint/
>>> 
>>> 
>>> On 18/01/13 17:06, Stéphane Ducasse wrote:
 Hi
 
 While looking at SmallLint rule, I saw a rule that ensures that a given 
 method always performs a
 super send.
 
 Here is the current list:
 
^#(#release #postCopy  #preBuildWith: #postOpenWith: 
 #noticeOfWindowClose: #initialize postBuildWith:)
 
 
 and I'm cleaning the list because there are VW elements such as 
 postBuildWith:
 but do we have some other to add?
 
 Stef
 
 
 
>>> 
>>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-project] NativeBoost and unions

[Marcus Denker]

On Jan 22, 2013, at 5:26 PM, Ciprian Teodorov  
wrote:

> Hi Igor,
> 
> as usual after squeaksource restart, i lost my commit rights on the 
> NativeBoost repository...
> 

Could NativeBoost move away from SqueakSource? SqueakSource is not stable.

> This time I have a small refactoring in the 
> NBExternalStruct/NBExternalStructFields to enable union support.
> 
> Besides that, c unions, I have implemented a first prototype, and now my 
> question for you is: Should I add it in nativeboost (its rightful place in my 
> opinion), 
> or should I keep it only as support code for my TalkFFI project(in 
> TalkFFI-runtime)? What do you think?
> 
> Cheers,
> Ciprian
> -- 
> Dr. Ciprian TEODOROV
> Ingénieur Développement CAO
> 
> tél : 06 08 54 73 48
> mail : ciprian.teodo...@gmail.com
> www.teodorov.ro

Re: [Pharo-project] DocTest

[Stéphane Ducasse]

it would be nice to introduce the same syntax than Sunit

exp assert: exp2

[ exp ] shouldraise: 

Stef


On Jan 21, 2013, at 4:41 AM, Benjamin wrote:

> Hi guys,
> 
> I am attending a python lecture and discovered DocTest[1], and I was 
> wondering if such a tool exists for Pharo ? :)
> 
> 
> Ben
> 
> [1]http://docs.python.org/2/library/doctest.html
> 
> 

Re: [Pharo-project] Fonts in Pharo By Example

[Stéphane Ducasse]

On Jan 21, 2013, at 11:57 AM, Sean P. DeNigris wrote:

> It would be great to have a section in PBE2 about fonts. I find them very
> confusing - TrueType, FreeType, Logical, etc. Understanding how they're
> handled in Pharo requires background knowledge, and an overview and a few
> specific examples could really do some good.

If somebody explain it It would be great.
I always wanted to read something on fonts but unfortunately I feel a bit alone 
on the writing side
This is why I love the attitude of sven to produce doc.

Stef


> 
> Cheers,
> Sean
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] Closing unresolved issues

[Stéphane Ducasse]

Thanks for your feedback.
Sean and I understand your frustration.

The problem is what do we do if we have many bugs with nobody looking at them.


> For example...
> Issue 5656: Large fonts make tools slow
> http://code.google.com/p/pharo/issues/detail?id=5656
> 
> This issue has not been resolved, but the issue was closed, leading to this
> experience...
> - I just upgraded a project to 2.0
> - I notice that the UI is very slow - a simple Spec dialog window with a few
> text fields and buttons takes ~4 seconds to open
> - I check the issue tracker because I remember I reported the bug already,
> but I don't find it in the open issues
> - I waste time because I think it must be something else
> - I finally expand my search through the issues and find my report was
> closed as invalid
> 
> I'm not saying that this is wrong, just that I don't understand and want to
> share another perspective and come to the best solution...  What benefit are
> we getting from closing these that is significant enough to justify this
> kind of experience (I'm sure I'm not the only one).
> 
> Cheers,
> Sean
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Closing-unresolved-issues-tp4664420.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] [Issue Tracker] Status

[Sean P. DeNigris]

FixToInclude: http://code.google.com/p/pharo/issues/detail?id=7207



--
View this message in context: 
http://forum.world.st/Issue-Tracker-Status-tp4664590p4664606.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] Object>>#name

[Stéphane Ducasse]

> Sven Van Caekenberghe-2 wrote
>> Many people have hit the fact that Object implements #name, which then
>> seems to conflict with some other class where one would really like to use
>> name as an instance variable and thus accessor.
> 
> Yes, I've been bitten by this a few times. When developing through the
> debugger, it's confusing when the thing fails silently instead of prompting
> to create the method.
> 
> 
> Sven Van Caekenberghe-2 wrote
>> Turns out that it seems that Object>>#name is actually not used (anymore).
> 
> There are lots of senders... I guess they're sending Class>>#name or another
> message. I  say ditch it, but wait until 3.0…

+ 1
 
Open a bug entry for 3.0

Stef
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Object-name-tp4664573p4664583.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] Object>>#name

[Gary Chambers]

+1 to removal...

Regards, Gary

- Original Message - 
From: "Sean P. DeNigris" 

To: 
Sent: Tuesday, January 22, 2013 5:02 PM
Subject: Re: [Pharo-project] Object>>#name



Sven Van Caekenberghe-2 wrote

Many people have hit the fact that Object implements #name, which then
seems to conflict with some other class where one would really like to 
use

name as an instance variable and thus accessor.


Yes, I've been bitten by this a few times. When developing through the
debugger, it's confusing when the thing fails silently instead of 
prompting

to create the method.


Sven Van Caekenberghe-2 wrote
Turns out that it seems that Object>>#name is actually not used 
(anymore).


There are lots of senders... I guess they're sending Class>>#name or 
another

message. I  say ditch it, but wait until 3.0...



--
View this message in context: 
http://forum.world.st/Object-name-tp4664573p4664583.html

Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] DocTest

[Sean P. DeNigris]

Benjamin Van Ryseghem-2 wrote
> I am attending a python lecture and discovered DocTest[1], and I was
> wondering if such a tool exists for Pharo ? :)

I've been dreaming about, and doing experiments around, this for quite a
while... could be so much better in st because we can create custom UI tools
instead of text files...



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

Re: [Pharo-project] Closing unresolved issues

[Sean P. DeNigris]

Stéphane Ducasse wrote
> The problem is what do we do if we have many bugs with nobody looking at
> them.

Maybe a good compromise would be a status like "Stale", where we can exclude
them from searches if we want, but they are still being tracked?



--
View this message in context: 
http://forum.world.st/Closing-unresolved-issues-tp4664420p4664618.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

[Pharo-project] User Interrupt Broken?!

[Sean P. DeNigris]

Has anyone else noticed this? Open a fresh 2.0482 latest and hit Cmd-. a
bunch of times. If the debugger opens on the first, close it and keep
pressing the shortcut. Most presses seem to do nothing.



--
View this message in context: 
http://forum.world.st/User-Interrupt-Broken-tp4664619.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] [Issue Tracker] Status

[Sean P. DeNigris]

HumanReviewNeeded: http://code.google.com/p/pharo/issues/detail?id=7108



--
View this message in context: 
http://forum.world.st/Issue-Tracker-Status-tp4664590p4664623.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] Fwd: [Moose-dev] ZnUrl, Encoding

[Sven Van Caekenberghe]

Hi Dennis,

I don't know where you were trying this, it does not change the explanation, 
but in Pharo 2.0 with the latest Zinc HTTP Components code, your example gives 
an error:

  
'http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Curaçao&sensor=false&language=en'
 
asZnUrl retrieveContents.

  ZnCharacterEncodingError: ASCII character expected.

and rightfully so: an encoded URL cannot contain these characters. There is a 
difference between internal and external encoding of URLs and of ZnUrl.

One way to do it correctly is:

  'http://maps.googleapis.com/maps/api/geocode/json' asZnUrl
queryAt: #address put: 'Willemstad, Curaçao';
queryAt: #sensor put: 'false';
queryAt: #language put: #en;
retrieveContents.

Please check the extensive class comment of ZnUrl. Leave the problem of 
encoding to ZnUrl, supply the internal values directly ;-)

So why does it work in your browser ?

Because your browser's URL entry field has very permissive parsing, doing this 
conversion as an extra service, above what is required. ZnUrl is stricter.

HTH,

Sven

On 22 Jan 2013, at 15:13, "H. Hirzel"  wrote:

> I assume this question is better placed here 
> 
> I am interested in the answer as well.
> 
> --Hannes
> 
> -- Forwarded message --
> From: Dennis Schenk 
> Date: Tue, 22 Jan 2013 14:00:06 +0100
> Subject: [Moose-dev] ZnUrl, Encoding
> To: Moose-related development 
> 
> Hi all,
> 
> I stumpled upon a problem with encoding of URLs in Pharo.
> 
> I am using the Google Geocoding API. For example I want to get the result
> of:
> http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Curaçao&sensor=false&language=en
> 
> When one enters this in a Browser a correct JSON response is returned.
> 
> If I do the following:
> 
> *(Url absoluteFromText: '
> http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Curaçao&sensor=false&language=en')
> retrieveContents contents.*
> 
> I get an error back grom Google.
> 
> When digging through the code I found that in ZnHTTPSocketFacade the
> following happens:
> 
> *'
> http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Curaçao&sensor=false&language=en'
> asZnUrl *
> 
> And the result of this is:
> 
> http://maps.googleapis.com/maps/api/geocode/json?address=Willemstad,+Cura%C3%A7ao&sensor=false&language=en
> *
> *
> Which Google does not know how to handle and then returns an error.
> 
> Does anyone have an idea how I could get contents from a URL which has
> special chars like '*ç'?*
> 
> Or is there a way to convert all special chars to to their 'normal'
> counterparts, like *ç -> c?*
> *
> *
> Cheers,
> Dennis

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill

Re: [Pharo-project] NativeBoost and unions

[Esteban Lorenzano]

as all the core packages for pharo (and NB is one of them), it should be in 
smalltalkhub :)

On Jan 22, 2013, at 5:29 PM, Marcus Denker  wrote:

> 
> On Jan 22, 2013, at 5:26 PM, Ciprian Teodorov  
> wrote:
> 
>> Hi Igor,
>> 
>> as usual after squeaksource restart, i lost my commit rights on the 
>> NativeBoost repository...
>> 
> 
> Could NativeBoost move away from SqueakSource? SqueakSource is not stable.
> 
>> This time I have a small refactoring in the 
>> NBExternalStruct/NBExternalStructFields to enable union support.
>> 
>> Besides that, c unions, I have implemented a first prototype, and now my 
>> question for you is: Should I add it in nativeboost (its rightful place in 
>> my opinion), 
>> or should I keep it only as support code for my TalkFFI project(in 
>> TalkFFI-runtime)? What do you think?
>> 
>> Cheers,
>> Ciprian
>> -- 
>> Dr. Ciprian TEODOROV
>> Ingénieur Développement CAO
>> 
>> tél : 06 08 54 73 48
>> mail : ciprian.teodo...@gmail.com
>> www.teodorov.ro
> 

Re: [Pharo-project] Object>>#name

[Esteban Lorenzano]

+1 

On Jan 22, 2013, at 6:45 PM, "Gary Chambers"  wrote:

> +1 to removal...
> 
> Regards, Gary
> 
> - Original Message - From: "Sean P. DeNigris" 
> To: 
> Sent: Tuesday, January 22, 2013 5:02 PM
> Subject: Re: [Pharo-project] Object>>#name
> 
> 
>> Sven Van Caekenberghe-2 wrote
>>> Many people have hit the fact that Object implements #name, which then
>>> seems to conflict with some other class where one would really like to use
>>> name as an instance variable and thus accessor.
>> 
>> Yes, I've been bitten by this a few times. When developing through the
>> debugger, it's confusing when the thing fails silently instead of prompting
>> to create the method.
>> 
>> 
>> Sven Van Caekenberghe-2 wrote
>>> Turns out that it seems that Object>>#name is actually not used (anymore).
>> 
>> There are lots of senders... I guess they're sending Class>>#name or another
>> message. I  say ditch it, but wait until 3.0...
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://forum.world.st/Object-name-tp4664573p4664583.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 
> 

[Pharo-project] SmallLint applied on Pharo: Continued

[Stéphane Ducasse]

Hi 

I'm running the rule RBSubclassResponsibilityNotDefinedRule that

Checks that all subclassResponsibility methods are defined in all leaf 
classes.

Now the results display the sender of ^ subclassResponsibility but I have to 
manually find the
problems. I would be better to report the violations. Of course this is not 
that simple: returning a class and missing method.

But this would be much better. Jan did you do that in your version?

Stef

Re: [Pharo-project] Object>>#name

[Gary Chambers]

Indeed, is a common accessor for domain/business objects.
Have got use to having to re-implement each time myself but quicker to not 
have to.


Regards, Gary

- Original Message - 
From: "Sven Van Caekenberghe" 

To: 
Sent: Monday, January 21, 2013 6:43 PM
Subject: [Pharo-project] Object>>#name


Hi,

Many people have hit the fact that Object implements #name, which then seems 
to conflict with some other class where one would really like to use name as 
an instance variable and thus accessor.


Turns out that it seems that Object>>#name is actually not used (anymore).

I just put a halt in it and tried a couple of tools and everything seems to 
work just fine.


The comment talks about Inspector use, but there is 
#defaultLabelForInspector for that.


It is a small thing, but it confuses everybody for no good reason,

Any comments ?

Sven

PS: it was also in the testing procotol ;-)

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill

Re: [Pharo-project] Fonts in Pharo By Example

[Gary Chambers]

Have got used to using FreeType so always look up fonts via LogicalFont 
class methods these days...


headingFont
"Answer the font for headings."

^LogicalFont
 familyName: 'Arial' pointSize: 20

Regards, Gary

- Original Message - 
From: "Stéphane Ducasse" 

To: 
Sent: Tuesday, January 22, 2013 5:26 PM
Subject: Re: [Pharo-project] Fonts in Pharo By Example



On Jan 21, 2013, at 11:57 AM, Sean P. DeNigris wrote:


It would be great to have a section in PBE2 about fonts. I find them very
confusing - TrueType, FreeType, Logical, etc. Understanding how they're
handled in Pharo requires background knowledge, and an overview and a few
specific examples could really do some good.


If somebody explain it It would be great.
I always wanted to read something on fonts but unfortunately I feel a bit 
alone on the writing side

This is why I love the attitude of sven to produce doc.

Stef




Cheers,
Sean



--
View this message in context: 
http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406.html

Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] SmallLint applied on Pharo: Continued

[Jan Vrany]

On 22/01/13 18:22, Stéphane Ducasse wrote:

Hi

I'm running the rule RBSubclassResponsibilityNotDefinedRule that

Checks that all subclassResponsibility methods are defined in all leaf 
classes.

Now the results display the sender of ^ subclassResponsibility but I have to 
manually find the
problems. I would be better to report the violations. Of course this is not 
that simple: returning a class and missing method.

But this would be much better. Jan did you do that in your version?


Good point. Yes, since now we do that :-)

Jan



Stef

Re: [Pharo-project] Closing unresolved issues

[Marcus Denker]

On Jan 22, 2013, at 5:17 PM, Sean P. DeNigris  wrote:

> For example...
> Issue 5656: Large fonts make tools slow
> http://code.google.com/p/pharo/issues/detail?id=5656
> 
> This issue has not been resolved, but the issue was closed, leading to this
> experience...
> - I just upgraded a project to 2.0
> - I notice that the UI is very slow - a simple Spec dialog window with a few
> text fields and buttons takes ~4 seconds to open
> - I check the issue tracker because I remember I reported the bug already,
> but I don't find it in the open issues
> - I waste time because I think it must be something else
> - I finally expand my search through the issues and find my report was
> closed as invalid
> 
> I'm not saying that this is wrong, just that I don't understand and want to
> share another perspective and come to the best solution...  What benefit are
> we getting from closing these that is significant enough to justify this
> kind of experience (I'm sure I'm not the only one).
> 
Yes, I was too fast closing this report… I will open it again.

Marcus

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

[Marcus Denker]

On Jan 22, 2013, at 5:27 PM, H. Hirzel  wrote:

> Dave
> 
> I wonder why you can't check for
> 
>Smalltalk at: #OSPlatform
> 
> and if that exists go for
>OSPlatform osVersion
> 
We deprecated that… but I can un-deprecate.

> Neither Squeak nor Cuis do have an OSPlatform class.
> 
> Then you go for
>Smalltalk os version
> 

This works in Pharo 2.0… 

> Am I missing something here?
> 
> --Hannes
> 
> On 1/21/13, David T. Lewis  wrote:
>> Why is OSPlatform class>>osVersion deprecated but OSPlatform
>> class>>platformName
>> is not?
>> 
>> My suggestion would be to comment #osVersion as being a synonym for
>> #version,
>> but do not deprecate it. That would enable use of "Smalltalk os version",
>> and
>> it would also support "OSPlatform osVersion", both of which make logical
>> sense.
>> It would also maintain support for external packages that rely on
>> #osVersion
>> to figure out platform differences.
>> 
>> The reason that I am asking is that I am trying to find a way to make
>> OSProcess class>>osVersion work on Pharo 2.0, Pharo1.x, and the various
>> versions of Squeak and Cuis. I quite honestly cannot figure out any way to
>> add Pharo 2.0 without breaking one more more of the other supported images.
>> If OSPlatform class>>osVersion did not raise a deprecation warning, then
>> I could make it work.
>> 
>> Thanks,
>> Dave
>> 
>> 
>> 
> 

[Pharo-project] SmallLint journey: another rule :)

[Stéphane Ducasse]

Hi

I'm trying the Temporaries read before written and I have the impression that I 
found a bug in the 
RBReadBeforeWrittenTester class 
because it flags connections (but connections is not a temp but an instance 
variable).

Did anybody experience the same?

Stef

listenLoop
"Private! This loop is run in a separate process. It will establish up 
to maxQueueLength connections on the given port."
"Details: When out of sockets or queue is full, retry more frequently, 
since a socket may become available, space may open in the queue, or a 
previously queued connection may be aborted by the client, making it available 
for a fresh connection."
"Note: If the machine is disconnected from the network while the server 
is running, the currently waiting socket will go from 'isWaitingForConnection' 
to 'unconnected', and attempts to create new sockets will fail. When this 
happens, delete the broken socket and keep trying to create a socket in case 
the network connection is re-established. Connecting and disconnecting was 
tested under PPP on Mac system 8.1. It is not if this will work on other 
platforms.

Fixed to not accept the connection if the queue is full (gvc)."


| newConnection |

socket := Socket newTCP.
"We'll accept four simultanous connections at the same time"
socket listenOn: portNumber backlogSize: 4.
"If the listener is not valid then the we cannot use the
BSD style accept() mechanism."
socket isValid ifFalse: [^self oldStyleListenLoop].
[true] whileTrue: [
socket isValid ifFalse: [
"socket has stopped listening for some reason"
socket destroy.
(Delay forMilliseconds: 10) wait.
^self listenLoop ].
[newConnection := socket waitForAcceptFor: 10]
on: ConnectionTimedOut
do: [:ex | newConnection := nil].
(newConnection notNil and: [newConnection isConnected])
ifTrue: [(accessSema critical: [connections 
size < maxQueueLength])

^^



ifFalse: [newConnection close. 
newConnection := nil]]
ifFalse: [newConnection := nil].
(newConnection notNil and: [newConnection isConnected]) ifTrue: 
[
accessSema critical: [connections addLast: 
newConnection].
newConnection := nil.
self changed].
self pruneStaleConnections]. 

Re: [Pharo-project] Object>>#name

[Stéphane Ducasse]

hi gary

we will address it. :)

Stef

On Jan 22, 2013, at 3:31 PM, Gary Chambers wrote:

> Indeed, is a common accessor for domain/business objects.
> Have got use to having to re-implement each time myself but quicker to not 
> have to.
> 
> Regards, Gary
> 
> - Original Message - From: "Sven Van Caekenberghe" 
> To: 
> Sent: Monday, January 21, 2013 6:43 PM
> Subject: [Pharo-project] Object>>#name
> 
> 
> Hi,
> 
> Many people have hit the fact that Object implements #name, which then seems 
> to conflict with some other class where one would really like to use name as 
> an instance variable and thus accessor.
> 
> Turns out that it seems that Object>>#name is actually not used (anymore).
> 
> I just put a halt in it and tried a couple of tools and everything seems to 
> work just fine.
> 
> The comment talks about Inspector use, but there is #defaultLabelForInspector 
> for that.
> 
> It is a small thing, but it confuses everybody for no good reason,
> 
> Any comments ?
> 
> Sven
> 
> PS: it was also in the testing procotol ;-)
> 
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
> 
> 
> 

Re: [Pharo-project] SmallLint journey: another rule :)

[Stéphane Ducasse]

Jan's experience on it :)

!RBTempsReadBeforeWrittenRule class methodsFor:'accessing'!

tagsBasic
"Return an array of tags (symbols) of given rule. Any rule may
 arbitrary number of tags. Tag values are not predefined/fixed.
 See class documentation for list of common tags"

^#( #broken )


On Jan 22, 2013, at 4:16 PM, Stéphane Ducasse wrote:

> Hi
> 
> I'm trying the Temporaries read before written and I have the impression that 
> I found a bug in the 
> RBReadBeforeWrittenTester class 
> because it flags connections (but connections is not a temp but an instance 
> variable).
> 
> Did anybody experience the same?
> 
> Stef
> 
> listenLoop
>   "Private! This loop is run in a separate process. It will establish up 
> to maxQueueLength connections on the given port."
>   "Details: When out of sockets or queue is full, retry more frequently, 
> since a socket may become available, space may open in the queue, or a 
> previously queued connection may be aborted by the client, making it 
> available for a fresh connection."
>   "Note: If the machine is disconnected from the network while the server 
> is running, the currently waiting socket will go from 
> 'isWaitingForConnection' to 'unconnected', and attempts to create new sockets 
> will fail. When this happens, delete the broken socket and keep trying to 
> create a socket in case the network connection is re-established. Connecting 
> and disconnecting was tested under PPP on Mac system 8.1. It is not if this 
> will work on other platforms.
>   
>   Fixed to not accept the connection if the queue is full (gvc)."
> 
> 
>   | newConnection |
> 
>   socket := Socket newTCP.
>   "We'll accept four simultanous connections at the same time"
>   socket listenOn: portNumber backlogSize: 4.
>   "If the listener is not valid then the we cannot use the
>   BSD style accept() mechanism."
>   socket isValid ifFalse: [^self oldStyleListenLoop].
>   [true] whileTrue: [
>   socket isValid ifFalse: [
>   "socket has stopped listening for some reason"
>   socket destroy.
>   (Delay forMilliseconds: 10) wait.
>   ^self listenLoop ].
>   [newConnection := socket waitForAcceptFor: 10]
>   on: ConnectionTimedOut
>   do: [:ex | newConnection := nil].
>   (newConnection notNil and: [newConnection isConnected])
>   ifTrue: [(accessSema critical: [connections 
> size < maxQueueLength])
>   
> ^^
> 
> 
> 
>   ifFalse: [newConnection close. 
> newConnection := nil]]
>   ifFalse: [newConnection := nil].
>   (newConnection notNil and: [newConnection isConnected]) ifTrue: 
> [
>   accessSema critical: [connections addLast: 
> newConnection].
>   newConnection := nil.
>   self changed].
>   self pruneStaleConnections]. 

Re: [Pharo-project] SmallLint applied on Pharo: Continued

[Stéphane Ducasse]

Jan 
what is the license of your tags and other code?

Stef

On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:

> On 22/01/13 18:22, Stéphane Ducasse wrote:
>> Hi
>> 
>> I'm running the rule RBSubclassResponsibilityNotDefinedRule that
>> 
>>  Checks that all subclassResponsibility methods are defined in all leaf 
>> classes.
>> 
>> Now the results display the sender of ^ subclassResponsibility but I have to 
>> manually find the
>> problems. I would be better to report the violations. Of course this is not 
>> that simple: returning a class and missing method.
>> 
>> But this would be much better. Jan did you do that in your version?
> 
> Good point. Yes, since now we do that :-)
> 
> Jan
> 
>> 
>> Stef
>> 
> 
> 

Re: [Pharo-project] [Ann] New version of Mocketry

[Stéphane Ducasse]

On Jan 22, 2013, at 4:24 PM, Denis Kudriashov wrote:

> 2013/1/22 Stéphane Ducasse 
> ConfigurationOfMocketry
> Tests
>
> This is already exists many years (thank's Laurent Laffont for configuration)
>  
> SmallLint rules applied.
> 
> Never use it. I will try.

We are making the process smoother :)
Wait a bit :)
S.

Re: [Pharo-project] DocTest

[Benjamin]

With Nicolas Petton we implemented it yesterday afternoon :)

It's missing Nautilus integration, but the code is pretty much there :)

(I will provide the repo asap)

Ben

On Jan 22, 2013, at 6:46 PM, Sean P. DeNigris wrote:

> Benjamin Van Ryseghem-2 wrote
>> I am attending a python lecture and discovered DocTest[1], and I was
>> wondering if such a tool exists for Pharo ? :)
> 
> I've been dreaming about, and doing experiments around, this for quite a
> while... could be so much better in st because we can create custom UI tools
> instead of text files...
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/DocTest-tp4664547p4664617.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] Fonts in Pharo By Example

[Sean P. DeNigris]

Gary Chambers-4 wrote
> always look up fonts via LogicalFont class methods these days...

Thanks, Gary! That actually solved an immediate problem I was dealing with
:) And I'm hoping a font guru will take a deeper cut for us ignorant masses
;)



--
View this message in context: 
http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406p4664664.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] DocTest

[Denis Kudriashov]

2013/1/22 Stéphane Ducasse 

> it would be nice to introduce the same syntax than Sunit
>
> exp assert: exp2
>
> [ exp ] shouldraise:
>

StateSpecs (package separated from Mocketry) implements it. And such
"should" syntax extendable by pragmas. Your example looks like:

[exp] should raise: Error

It is implemented with main spec class RaisingExceptionSpec
RaisingExceptionSpec >>basicMatches: aBlockContext
[aBlockContext value.
   ^false] on: requiredException
do:
[:ex |
ex class = SpecFailed ifTrue: [ex outer].
^true]
And single method in special DSL class:
Raise>>exception: aClass

^RaisingExceptionSpec requiredException: aClass


> Stef
>
>
> On Jan 21, 2013, at 4:41 AM, Benjamin wrote:
>
> > Hi guys,
> >
> > I am attending a python lecture and discovered DocTest[1], and I was
> wondering if such a tool exists for Pharo ? :)
> >
> >
> > Ben
> >
> > [1]http://docs.python.org/2/library/doctest.html
> >
> >
>
>
>

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

[David T. Lewis]

On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote:
> 
> On Jan 22, 2013, at 5:27 PM, H. Hirzel  wrote:
> 
> > Dave
> > 
> > I wonder why you can't check for
> > 
> >Smalltalk at: #OSPlatform
> > 
> > and if that exists go for
> >OSPlatform osVersion
> > 
> We deprecated that? but I can un-deprecate.
> 
> > Neither Squeak nor Cuis do have an OSPlatform class.
> > 
> > Then you go for
> >Smalltalk os version
> > 
> 
> This works in Pharo 2.0? 

Yes, "Smalltalk os version" is right for Pharo 2.0.

I'm looking for a way to modify the following method so that it adds support
for Pharo 2.0, so that it continues to work in the other images, and so that
it does not raise deprecation warnings or DNUs in any of the images.

OSProcess class>>osVersion
"After Squeak version 3.6, #osVersion was moved to SmalltalkImage. Some
versions of Pharo move this to OSPlatform and issue deprecation warnings
about the other usages."

^ (((Smalltalk hasClassNamed: #OSPlatform)
and: [(Smalltalk at: #OSPlatform)
respondsTo: #osVersion])
ifTrue: [Smalltalk at: #OSPlatform]
ifFalse: [((Smalltalk classNamed: 'SmalltalkImage')
ifNil: [^ Smalltalk osVersion]) current]) 
osVersion

Dave


> 
> > Am I missing something here?
> > 
> > --Hannes
> > 
> > On 1/21/13, David T. Lewis  wrote:
> >> Why is OSPlatform class>>osVersion deprecated but OSPlatform
> >> class>>platformName
> >> is not?
> >> 
> >> My suggestion would be to comment #osVersion as being a synonym for
> >> #version,
> >> but do not deprecate it. That would enable use of "Smalltalk os version",
> >> and
> >> it would also support "OSPlatform osVersion", both of which make logical
> >> sense.
> >> It would also maintain support for external packages that rely on
> >> #osVersion
> >> to figure out platform differences.
> >> 
> >> The reason that I am asking is that I am trying to find a way to make
> >> OSProcess class>>osVersion work on Pharo 2.0, Pharo1.x, and the various
> >> versions of Squeak and Cuis. I quite honestly cannot figure out any way to
> >> add Pharo 2.0 without breaking one more more of the other supported images.
> >> If OSPlatform class>>osVersion did not raise a deprecation warning, then
> >> I could make it work.
> >> 
> >> Thanks,
> >> Dave
> >> 
> >> 
> >> 
> > 
> 

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

[David T. Lewis]

On Tue, Jan 22, 2013 at 09:15:32AM -0800, Sean P. DeNigris wrote:
> David T. Lewis wrote
> > I am trying to find a way to make OSProcess... work on Pharo 2.0,
> > Pharo1.x, and the various versions of Squeak and Cuis
> 
> I've been thinking a lot about keeping OSP working well on all our favorite
> St platforms. Metacello was designed specifically to address this type of
> problem, which I'm sure will multiply as squeak and pharo evolve. I wonder
> if MetaC works with Cuis... If not, and for older versions of Squeak/Pharo,
> there could be a Gofer/Installer script like the one for FFI, or - easier
> for users but maybe a little more work - the multiple packages could be
> loaded in each supported platform and re-commited as a single
> platform-specific package e.g. OSProcessSqueak44, OSProcessPharo20; so
> development would be done w. MetaC, and users can simply download one
> package. This would also free us from the branching that currently exists to
> figure out which system we're on. Are you open to committing to the
> multiple-package path going forward and relying on MetaC to manage these
> incompatibilities?

Metacello will certainly handle this, and I certainly don't mind as long
as I don't get stuck doing the maintenance chores for all the different
images. I don't want to do Metacello configs for Squeak (because it is not
necessary) or Cuis (I don't know if it is possible and I don't have the time),
but it would be a good approach to support the more rapid rate of change in
Pharo.

My first preference would be to have the OSProcess package be clever enough
to adapt to the various image variations, but that may not be feasible if
the images get too different. Maybe we are at that point now, in which case
maintaining Metacello configurations for Pharo 2.0, 1.4, etc would be the
right thing to do.

Dave

Re: [Pharo-project] SmallLint applied on Pharo: Continued

[Jan Vrany]

Well. I've written the tag support, so let's make it simple, MIT.
I may export a changeset with that code for you, if you like.

For rules written by CG I'm not sure. You should check with him.
But I think it won't be a problem given that you preserve all
the signatures and #documentation and #version_XXX methods
(we use them to track changes in the source).

However, what I planned (and run out of time :-) is to make
tag a first class object with name (symbol) description etc
and have class methods to create them. Then one may define and
describe meaning of the tag in an extension method.
Also, the selection/rejection logic could dispatch back on
the tag instance so you may then create fancy dynamic tags
(like #portability that automatically includes everything tagged
as #pharo #squeak #stx #va, for instance or whatever.

I might hack it later this week, if you would include it into
your version (otherwise I've more important things to do :-)

Cheers

On 22/01/13 19:32, Stéphane Ducasse wrote:

Jan
what is the license of your tags and other code?

Stef

On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:


On 22/01/13 18:22, Stéphane Ducasse wrote:

Hi

I'm running the rule RBSubclassResponsibilityNotDefinedRule that

Checks that all subclassResponsibility methods are defined in all leaf 
classes.

Now the results display the sender of ^ subclassResponsibility but I have to 
manually find the
problems. I would be better to report the violations. Of course this is not 
that simple: returning a class and missing method.

But this would be much better. Jan did you do that in your version?


Good point. Yes, since now we do that :-)

Jan



Stef

Re: [Pharo-project] Fonts in Pharo By Example

[Gary Chambers]

No prob

Regards, Gary

- Original Message - 
From: "Sean P. DeNigris" 

To: 
Sent: Tuesday, January 22, 2013 7:54 PM
Subject: Re: [Pharo-project] Fonts in Pharo By Example



Gary Chambers-4 wrote

always look up fonts via LogicalFont class methods these days...


Thanks, Gary! That actually solved an immediate problem I was dealing with
:) And I'm hoping a font guru will take a deeper cut for us ignorant 
masses

;)



--
View this message in context: 
http://forum.world.st/Fonts-in-Pharo-By-Example-tp4664406p4664664.html

Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] DocTest

[Denis Kudriashov]

2013/1/22 Sean P. DeNigris 

> Benjamin Van Ryseghem-2 wrote
> > I am attending a python lecture and discovered DocTest[1], and I was
> > wondering if such a tool exists for Pharo ? :)
>
> I've been dreaming about, and doing experiments around, this for quite a
> while... could be so much better in st because we can create custom UI
> tools
> instead of text files...
>

I dream about it too :)). I remember we talk about this in Gent. But what
experiments are you talk about? How I can try it?
I think BDD programming can be much better and simpler with smalltalk
because we are not limited with text files and code syntax. We can work
with objects and present it with any way we want.
With classic TDD we model system specs with test methods which are very
restricted way for building readable and reusable specs of system. And I
think we mix here few concepts: how to validate (run) specs, how to persist
specs and what specs actualy is. And last item is what we should
reimplement from scrach independently from others (we should forgot about
others for the moment). BDD exactly about it. But nonsmalltalk world
continue mix concepts because text files and code syntax is only way to
persist and build system specs there. They was make just good refactoring
of TDD approach which is very nice but I'm sure we can do better :)

Re: [Pharo-project] SmallLint journey: another rule :)

[Sven Van Caekenberghe]

On 22 Jan 2013, at 20:16, Stéphane Ducasse  wrote:

> Hi
> 
> I'm trying the Temporaries read before written and I have the impression that 
> I found a bug in the 
> RBReadBeforeWrittenTester class 
> because it flags connections (but connections is not a temp but an instance 
> variable).
> 
> Did anybody experience the same?

Yes, I have seen it and I didn't understand…

> Stef
> 
> listenLoop
>   "Private! This loop is run in a separate process. It will establish up 
> to maxQueueLength connections on the given port."
>   "Details: When out of sockets or queue is full, retry more frequently, 
> since a socket may become available, space may open in the queue, or a 
> previously queued connection may be aborted by the client, making it 
> available for a fresh connection."
>   "Note: If the machine is disconnected from the network while the server 
> is running, the currently waiting socket will go from 
> 'isWaitingForConnection' to 'unconnected', and attempts to create new sockets 
> will fail. When this happens, delete the broken socket and keep trying to 
> create a socket in case the network connection is re-established. Connecting 
> and disconnecting was tested under PPP on Mac system 8.1. It is not if this 
> will work on other platforms.
>   
>   Fixed to not accept the connection if the queue is full (gvc)."
> 
> 
>   | newConnection |
> 
>   socket := Socket newTCP.
>   "We'll accept four simultanous connections at the same time"
>   socket listenOn: portNumber backlogSize: 4.
>   "If the listener is not valid then the we cannot use the
>   BSD style accept() mechanism."
>   socket isValid ifFalse: [^self oldStyleListenLoop].
>   [true] whileTrue: [
>   socket isValid ifFalse: [
>   "socket has stopped listening for some reason"
>   socket destroy.
>   (Delay forMilliseconds: 10) wait.
>   ^self listenLoop ].
>   [newConnection := socket waitForAcceptFor: 10]
>   on: ConnectionTimedOut
>   do: [:ex | newConnection := nil].
>   (newConnection notNil and: [newConnection isConnected])
>   ifTrue: [(accessSema critical: [connections 
> size < maxQueueLength])
>   
> ^^
> 
> 
> 
>   ifFalse: [newConnection close. 
> newConnection := nil]]
>   ifFalse: [newConnection := nil].
>   (newConnection notNil and: [newConnection isConnected]) ifTrue: 
> [
>   accessSema critical: [connections addLast: 
> newConnection].
>   newConnection := nil.
>   self changed].
>   self pruneStaleConnections]. 

[Pharo-project] Fwd: [squeak-dev] The Inbox: Monticello-nice.528.mcz

[Sven Van Caekenberghe]

Probably worth picking up:

Begin forwarded message:

> From: Bert Freudenberg 
> Subject: Re: [squeak-dev] The Inbox: Monticello-nice.528.mcz
> Date: 22 Jan 2013 20:12:14 GMT+01:00
> To: squeak-...@lists.squeakfoundation.org
> Reply-To: The general-purpose Squeak developers list 
> 
> 
> 
> On 22.01.2013, at 14:42, comm...@source.squeak.org wrote:
> 
>> A new version of Monticello was added to project The Inbox:
>> http://source.squeak.org/inbox/Monticello-nice.528.mcz
>> 
>>  Summary 
>> 
>> Name: Monticello-nice.528
>> Author: nice
>> Time: 22 January 2013, 3:42:35.787 pm
>> UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5
>> Ancestors: Monticello-bf.527
>> 
>> Let MCTool inherit from Model.
>> This is to avoid nasty garbage to survive in DependentsFields with kilo 
>> bytes of un-released MCDefinition cache.
> 
> Looks reasonable. Commit it and we'll find out soon if there are problems.
> 
> - Bert -

Re: [Pharo-project] Object>>#name

[Sven Van Caekenberghe]

On 22 Jan 2013, at 20:24, Stéphane Ducasse  wrote:

> hi gary
> 
> we will address it. :)
> 
> Stef

http://code.google.com/p/pharo/issues/detail?id=7304

> On Jan 22, 2013, at 3:31 PM, Gary Chambers wrote:
> 
>> Indeed, is a common accessor for domain/business objects.
>> Have got use to having to re-implement each time myself but quicker to not 
>> have to.
>> 
>> Regards, Gary
>> 
>> - Original Message - From: "Sven Van Caekenberghe" 
>> To: 
>> Sent: Monday, January 21, 2013 6:43 PM
>> Subject: [Pharo-project] Object>>#name
>> 
>> 
>> Hi,
>> 
>> Many people have hit the fact that Object implements #name, which then seems 
>> to conflict with some other class where one would really like to use name as 
>> an instance variable and thus accessor.
>> 
>> Turns out that it seems that Object>>#name is actually not used (anymore).
>> 
>> I just put a halt in it and tried a couple of tools and everything seems to 
>> work just fine.
>> 
>> The comment talks about Inspector use, but there is 
>> #defaultLabelForInspector for that.
>> 
>> It is a small thing, but it confuses everybody for no good reason,
>> 
>> Any comments ?
>> 
>> Sven
>> 
>> PS: it was also in the testing procotol ;-)
>> 
>> --
>> Sven Van Caekenberghe
>> http://stfx.eu
>> Smalltalk is the Red Pill
>> 
>> 
>> 
> 
> 

Re: [Pharo-project] DocTest

[Benjamin]

You can have a look here

Gofer it
url: 'http://smalltalkhub.com/mc/BenjaminVanRyseghem/DocTest/main';
package: 'DocTest';
load.

Then you can have a look at the test to see how it works :)

Basically MockCommentWithValidTests is a class with a comment containing valid 
test
then you can do

(DocTest testClass: MockCommentWithValidTests) run

It will run the test, and notify if something is wrong

Ben


On Jan 22, 2013, at 9:49 PM, Denis Kudriashov wrote:

> 2013/1/22 Sean P. DeNigris 
> Benjamin Van Ryseghem-2 wrote
> > I am attending a python lecture and discovered DocTest[1], and I was
> > wondering if such a tool exists for Pharo ? :)
> 
> I've been dreaming about, and doing experiments around, this for quite a
> while... could be so much better in st because we can create custom UI tools
> instead of text files...
> 
> I dream about it too :)). I remember we talk about this in Gent. But what 
> experiments are you talk about? How I can try it?
> I think BDD programming can be much better and simpler with smalltalk because 
> we are not limited with text files and code syntax. We can work with objects 
> and present it with any way we want. 
> With classic TDD we model system specs with test methods which are very 
> restricted way for building readable and reusable specs of system. And I 
> think we mix here few concepts: how to validate (run) specs, how to persist 
> specs and what specs actualy is. And last item is what we should reimplement 
> from scrach independently from others (we should forgot about others for the 
> moment). BDD exactly about it. But nonsmalltalk world continue mix concepts 
> because text files and code syntax is only way to persist and build system 
> specs there. They was make just good refactoring of TDD approach which is 
> very nice but I'm sure we can do better :)
> 
> 

Re: [Pharo-project] Fwd: [squeak-dev] The Inbox: Monticello-nice.528.mcz

[Nicolas Cellier]

Probably not, it was not the right interpretation...

2013/1/22 Sven Van Caekenberghe :
> Probably worth picking up:
>
> Begin forwarded message:
>
>> From: Bert Freudenberg 
>> Subject: Re: [squeak-dev] The Inbox: Monticello-nice.528.mcz
>> Date: 22 Jan 2013 20:12:14 GMT+01:00
>> To: squeak-...@lists.squeakfoundation.org
>> Reply-To: The general-purpose Squeak developers list 
>> 
>>
>>
>> On 22.01.2013, at 14:42, comm...@source.squeak.org wrote:
>>
>>> A new version of Monticello was added to project The Inbox:
>>> http://source.squeak.org/inbox/Monticello-nice.528.mcz
>>>
>>>  Summary 
>>>
>>> Name: Monticello-nice.528
>>> Author: nice
>>> Time: 22 January 2013, 3:42:35.787 pm
>>> UUID: 3bc3c4a2-2ec6-e942-9517-5da75b32bac5
>>> Ancestors: Monticello-bf.527
>>>
>>> Let MCTool inherit from Model.
>>> This is to avoid nasty garbage to survive in DependentsFields with kilo 
>>> bytes of un-released MCDefinition cache.
>>
>> Looks reasonable. Commit it and we'll find out soon if there are problems.
>>
>> - Bert -
>
>

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

[Chris Cunningham]

On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis wrote:

> On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote:
> >
> > On Jan 22, 2013, at 5:27 PM, H. Hirzel  wrote:
> >
> > > Dave
> > >>
> > This works in Pharo 2.0?
>
> Yes, "Smalltalk os version" is right for Pharo 2.0.
>
> I'm looking for a way to modify the following method so that it adds
> support
> for Pharo 2.0, so that it continues to work in the other images, and so
> that
> it does not raise deprecation warnings or DNUs in any of the images.
>

Could you capture for deprecation of OSPlatform osVersion, and resend the
other method (Smalltalk osVersion current osVersion)?  Or, trap for
Deprecation and resume it (ignore deprecation - once it is removed, you'll
automatically fail-over to the new code).

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

[David T. Lewis]

On Tue, Jan 22, 2013 at 01:51:56PM -0800, Chris Cunningham wrote:
> On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis wrote:
> 
> > On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote:
> > >
> > > On Jan 22, 2013, at 5:27 PM, H. Hirzel  wrote:
> > >
> > > > Dave
> > > >>
> > > This works in Pharo 2.0?
> >
> > Yes, "Smalltalk os version" is right for Pharo 2.0.
> >
> > I'm looking for a way to modify the following method so that it adds
> > support
> > for Pharo 2.0, so that it continues to work in the other images, and so
> > that
> > it does not raise deprecation warnings or DNUs in any of the images.
> >
> 
> Could you capture for deprecation of OSPlatform osVersion, and resend the
> other method (Smalltalk osVersion current osVersion)?  Or, trap for
> Deprecation and resume it (ignore deprecation - once it is removed, you'll
> automatically fail-over to the new code).

No, Pharo 2.0 is writing console output whenever an exception occurs, so
catching the exception is not good. But not raising the exception in the
first place works just fine ;)

Dave

Re: [Pharo-project] SmallLint applied on Pharo: Continued

[Stéphane Ducasse]

> Well. I've written the tag support, so let's make it simple, MIT.
> I may export a changeset with that code for you, if you like.

Else I will just go over them and it will help me to understand. I think that 
this is not difficult. 

> For rules written by CG I'm not sure. You should check with him.
> But I think it won't be a problem given that you preserve all
> the signatures and #documentation and #version_XXX methods
> (we use them to track changes in the source).
> 
> However, what I planned (and run out of time :-) is to make
> tag a first class object with name (symbol) description etc
> and have class methods to create them. Then one may define and
> describe meaning of the tag in an extension method.
> Also, the selection/rejection logic could dispatch back on
> the tag instance so you may then create fancy dynamic tags
> (like #portability that automatically includes everything tagged
> as #pharo #squeak #stx #va, for instance or whatever.
> 
> I might hack it later this week, if you would include it into
> your version (otherwise I've more important things to do :-)

I imagine well.
Let us keep it simple. Simple tags with a little class comments are good enough 
:)

> 
> Cheers
> 
> On 22/01/13 19:32, Stéphane Ducasse wrote:
>> Jan
>> what is the license of your tags and other code?
>> 
>> Stef
>> 
>> On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
>> 
>>> On 22/01/13 18:22, Stéphane Ducasse wrote:
 Hi
 
 I'm running the rule RBSubclassResponsibilityNotDefinedRule that
 
Checks that all subclassResponsibility methods are defined in all leaf 
 classes.
 
 Now the results display the sender of ^ subclassResponsibility but I have 
 to manually find the
 problems. I would be better to report the violations. Of course this is 
 not that simple: returning a class and missing method.
 
 But this would be much better. Jan did you do that in your version?
>>> 
>>> Good point. Yes, since now we do that :-)
>>> 
>>> Jan
>>> 
 
 Stef
 
>>> 
>>> 
>> 
>> 
>> 
> 
> 

[Pharo-project] Athens replacement for ImageReadWriter?

[Esteban Lorenzano]

Hi, 

So, ImageReadWriter currently reads image files and retrieve Form objects, who 
can be displayed in world... 
anybody knows (cough, cough, Igor) what would be the Athens replacement for 
that?

thanks,
Esteban

Re: [Pharo-project] DocTest

[Camillo Bruni]

for that we already have a fully working Phexample:

http://www.squeaksource.com/phexample.html

which I will push in 3.0, cause I never really liked #assert: and friends being
sent to self. Furthermore we could finally build up decent messages!

On 2013-01-22, at 18:24, Stéphane Ducasse  wrote:

> it would be nice to introduce the same syntax than Sunit
> 
>   exp assert: exp2
> 
>   [ exp ] shouldraise: 
> 
> Stef
> 
> 
> On Jan 21, 2013, at 4:41 AM, Benjamin wrote:
> 
>> Hi guys,
>> 
>> I am attending a python lecture and discovered DocTest[1], and I was 
>> wondering if such a tool exists for Pharo ? :)
>> 
>> 
>> Ben
>> 
>> [1]http://docs.python.org/2/library/doctest.html
>> 
>> 
> 
> 

Re: [Pharo-project] NativeBoost and unions

[Camillo Bruni]

yes please!

On 2013-01-22, at 19:10, Esteban Lorenzano  wrote:

> as all the core packages for pharo (and NB is one of them), it should be in 
> smalltalkhub :)
> 
> On Jan 22, 2013, at 5:29 PM, Marcus Denker  wrote:
> 
>> 
>> On Jan 22, 2013, at 5:26 PM, Ciprian Teodorov  
>> wrote:
>> 
>>> Hi Igor,
>>> 
>>> as usual after squeaksource restart, i lost my commit rights on the 
>>> NativeBoost repository...
>>> 
>> 
>> Could NativeBoost move away from SqueakSource? SqueakSource is not stable.
>> 
>>> This time I have a small refactoring in the 
>>> NBExternalStruct/NBExternalStructFields to enable union support.
>>> 
>>> Besides that, c unions, I have implemented a first prototype, and now my 
>>> question for you is: Should I add it in nativeboost (its rightful place in 
>>> my opinion), 
>>> or should I keep it only as support code for my TalkFFI project(in 
>>> TalkFFI-runtime)? What do you think?
>>> 
>>> Cheers,
>>> Ciprian
>>> -- 
>>> Dr. Ciprian TEODOROV
>>> Ingénieur Développement CAO
>>> 
>>> tél : 06 08 54 73 48
>>> mail : ciprian.teodo...@gmail.com
>>> www.teodorov.ro
>> 
> 

Re: [Pharo-project] User Interrupt Broken?!

[Camillo Bruni]

have you tried an older StackVM, I remember getting this behavior with more
certainty under the CogVM...

On 2013-01-22, at 18:51, "Sean P. DeNigris"  wrote:

> Has anyone else noticed this? Open a fresh 2.0482 latest and hit Cmd-. a
> bunch of times. If the debugger opens on the first, close it and keep
> pressing the shortcut. Most presses seem to do nothing.
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/User-Interrupt-Broken-tp4664619.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 

Re: [Pharo-project] User Interrupt Broken?!

[Sean P. DeNigris]

Camillo Bruni-3 wrote
> have you tried an older StackVM

I can't even start a fresh 2.0482 image with a stack vm. I tried an old one
from early 2012, and the oldest and newest from the static file server.



--
View this message in context: 
http://forum.world.st/User-Interrupt-Broken-tp4664619p4664744.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] User Interrupt Broken?!

[David T. Lewis]

Keep in mind that responding to the user interrupt key can be timing dependent,
so differences between the behavior of Cog and interpreter VMs may be nothing
more than the effect of a faster versus slower VM running the same image. It
does not mean that Cog is more (or less) error prone, it might be just that Cog
is arriving at the error condition faster.

Basically, the VM will try to figure out what process was *probably* running at
the time of the user interrupt (but this is really only a guess as to which 
process
the user intended to interrupt), and the image needs to figure out what process
to interrupt in a debugger based on whatever it can learn out from the VM. This
is not an entirely reliable operation ;)

Dave

On Wed, Jan 23, 2013 at 01:17:18AM +0100, Camillo Bruni wrote:
> have you tried an older StackVM, I remember getting this behavior with more
> certainty under the CogVM...
> 
> On 2013-01-22, at 18:51, "Sean P. DeNigris"  wrote:
> 
> > Has anyone else noticed this? Open a fresh 2.0482 latest and hit Cmd-. a
> > bunch of times. If the debugger opens on the first, close it and keep
> > pressing the shortcut. Most presses seem to do nothing.
> > 
> > 
> > 
> > --
> > View this message in context: 
> > http://forum.world.st/User-Interrupt-Broken-tp4664619.html
> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> > 
> 

Re: [Pharo-project] iCal port to Magritte3

[Yanni Chiu]

Hmmm. It seems the ConfigurationOf is expecting GemStone and Squeak, not 
Pharo.


Yikes, the differences in Date, Time, DateAndTime, timezones, etc. 
across dialects and versions is a *challenge*.


I probably don't need Magritte3. I just want to create ical files.

[Aside. I wish there were a mailing list for cross-platform packages]


On 22/01/13 3:05 PM, Yanni Chiu wrote:

I just started to look at ical on squeaksource, and am happy to find
it's actively being worked on.

Is anyone working on porting iCalMagritte to Magritte3?
Should I do it, and call it iCalMagritte3? Then we'd have two dev
streams to maintain.

There are some minor problems with the code.

- ICalChronos-PaulDeBruicker.5 is not in the repository (maybe lost to a
squeaksource restart)
- the test class StafferDateAndTime is not defined anywhere (maybe it's
in the missing package)

Re: [Pharo-project] DocTest

[Tudor Girba]

+1

Doru


On Jan 23, 2013, at 1:07 AM, Camillo Bruni  wrote:

> for that we already have a fully working Phexample:
> 
> http://www.squeaksource.com/phexample.html
> 
> which I will push in 3.0, cause I never really liked #assert: and friends 
> being
> sent to self. Furthermore we could finally build up decent messages!
> 
> On 2013-01-22, at 18:24, Stéphane Ducasse  wrote:
> 
>> it would be nice to introduce the same syntax than Sunit
>> 
>>  exp assert: exp2
>> 
>>  [ exp ] shouldraise: 
>> 
>> Stef
>> 
>> 
>> On Jan 21, 2013, at 4:41 AM, Benjamin wrote:
>> 
>>> Hi guys,
>>> 
>>> I am attending a python lecture and discovered DocTest[1], and I was 
>>> wondering if such a tool exists for Pharo ? :)
>>> 
>>> 
>>> Ben
>>> 
>>> [1]http://docs.python.org/2/library/doctest.html
>>> 
>>> 
>> 
>> 
> 
> 

--
www.tudorgirba.com

"Every thing should have the right to be different."

[Pharo-project] pharotaskforces broken on squeaksource

[Tudor Girba]

Hi,

It seems that the http://www.squeaksource.com/PharoTaskForces repository is 
broken.

When I try to connect to it via Monticello, I get a "SubscriptOutOfBounds: 0". 
The problem seems to be that the repository somehow has a file called '.mcz' 
(which is obviously wrong):

(MCHttpRepository
location: 'http://www.squeaksource.com/PharoTaskForces'
user: ''
password: '') readableFileNames select: [:each | each beginsWith: '.']


Anyone know why this happened? Or how to fix this?


Cheers,
Doru


--
www.tudorgirba.com

"It's not how it is, it is how we see it."

[Pharo-project] OrderedCollections and File I/O

[J . P . L . Martín]

Say I have an OrderedCollection which I want to save into a file and then
recover from that file when I restart the application. How should I
proceed? So far I've been doing a mess, saving the OrderedCollection on a
file asString, since I'm then unable to recover it asOrderedCollection.

Another problem that I have is at the moment of showing items from that
OrderedCollection on a MultiColumnListMorph where I get unwanted info from
the printOn:

a Prestamo fechaPrevistaDevolucion: 20 January 2013 fechaPrestamo: 17
January 2013 id: ''1'' idSocio: ''2'' idEjemplarl: ''1'' fechaDevolucion:
'

Where I want:

20 January 2013 17 January 2013 1 2 1 ''

Here you can find the source code:
https://github.com/arguser/Paradigmas-Final

Re: [Pharo-project] [GS/SS Beta] iCal port to Magritte3

[Paul DeBruicker]

Hi Yanni,

My mistake.  StafferDateAndTime class is my subclass of the Chronos
class Timepoint.  Those references can be replaced with 'self
dateAndTimeClass' sends.


I removed the offending references and put the corrected version and the
missing version if ICalChronos up on Squeaksource.   The
ConfigurationOfICal should work on both Pharo and Squeak.  I have not
tested it in Gemstone.  Or were you referring to a different
ConfigurationOf?


I have not done anything with iCalMagritte or Magritte3 so can't help
you there.

Let me know if it works for you now and  how else I can help

Thanks
Paul




On 01/22/2013 07:57 PM, Yanni Chiu wrote:
> Hmmm. It seems the ConfigurationOf is expecting GemStone and Squeak, not
> Pharo.
> 
> Yikes, the differences in Date, Time, DateAndTime, timezones, etc.
> across dialects and versions is a *challenge*.
> 
> I probably don't need Magritte3. I just want to create ical files.
> 
> [Aside. I wish there were a mailing list for cross-platform packages]
> 
> 
> On 22/01/13 3:05 PM, Yanni Chiu wrote:
>> I just started to look at ical on squeaksource, and am happy to find
>> it's actively being worked on.
>>
>> Is anyone working on porting iCalMagritte to Magritte3?
>> Should I do it, and call it iCalMagritte3? Then we'd have two dev
>> streams to maintain.
>>
>> There are some minor problems with the code.
>>
>> - ICalChronos-PaulDeBruicker.5 is not in the repository (maybe lost to a
>> squeaksource restart)
>> - the test class StafferDateAndTime is not defined anywhere (maybe it's
>> in the missing package)
> 

Re: [Pharo-project] [GS/SS Beta] iCal port to Magritte3

[Yanni Chiu]

On 22/01/13 11:31 PM, Paul DeBruicker wrote:


My mistake.  StafferDateAndTime class is my subclass of the Chronos
class Timepoint.  Those references can be replaced with 'self
dateAndTimeClass' sends.


I tried creating StafferDateAndTime as a subclass of DateAndTime, but 
there were still problems. Right now I've gone back to iCal-pmm.74.mcz, 
which does not have your extra iCal features. With fewer failing tests, 
I'm working through them - on Pharo-1.4.


I think the problems are due to how the local timezone offset is being 
handled. Once I get a handle on what's going on, I'll try with your 
later versions.



I removed the offending references and put the corrected version and the
missing version if ICalChronos up on Squeaksource.   The
ConfigurationOfICal should work on both Pharo and Squeak.  I have not
tested it in Gemstone.  Or were you referring to a different
ConfigurationOf?


I'm using the ConfigurationOf that's in the ical squeaksource repo. I'm 
not sure whether Chronos is supposed to work on Pharo. Anyway, if it's 
optional for iCal, then I don't need it. However, I suspect some of your 
extra iCal features may be dependent on Chronos though.

Re: [Pharo-project] Athens replacement for ImageReadWriter?

[Denis Kudriashov]

I have same question :))

2013/1/23 Esteban Lorenzano 

> Hi,
>
> So, ImageReadWriter currently reads image files and retrieve Form objects,
> who can be displayed in world...
> anybody knows (cough, cough, Igor) what would be the Athens replacement
> for that?
>
> thanks,
> Esteban
>
>
>

Re: [Pharo-project] OrderedCollections and File I/O

[H. Hirzel]

On 1/23/13, J. P. L. Martín  wrote:
> Say I have an OrderedCollection which I want to save into a file and then
> recover from that file when I restart the application. How should I
> proceed? So far I've been doing a mess, saving the OrderedCollection on a
> file asString, since I'm then unable to recover it asOrderedCollection.

Maybe you'll have a look at SandstoneDB

http://onsmalltalk.com/sandstonedb-simple-activerecord-style-persistence-in-squeak

I do not know where the most recent version for Pharo 1.4 is, but I'm
sure somebody else can answer that.

--Hannes


> Another problem that I have is at the moment of showing items from that
> OrderedCollection on a MultiColumnListMorph where I get unwanted info from
> the printOn:
>
> a Prestamo fechaPrevistaDevolucion: 20 January 2013 fechaPrestamo: 17
> January 2013 id: ''1'' idSocio: ''2'' idEjemplarl: ''1'' fechaDevolucion:
> '
>
> Where I want:
>
> 20 January 2013 17 January 2013 1 2 1 ''
>
> Here you can find the source code:
> https://github.com/arguser/Paradigmas-Final
>

Re: [Pharo-project] OrderedCollections and File I/O

[Dennis Schetinin]

Fuel: http://rmod.lille.inria.fr/web/pier/software/Fuel


Best regards,
Dennis Schetinin


On Wednesday, 23 January 2013 г. at 8:24, J. P. L. Martín wrote:

> Say I have an OrderedCollection which I want to save into a file and then 
> recover from that file when I restart the application. How should I proceed? 
> So far I've been doing a mess, saving the OrderedCollection on a file 
> asString, since I'm then unable to recover it asOrderedCollection.
>  
> Another problem that I have is at the moment of showing items from that 
> OrderedCollection on a MultiColumnListMorph where I get unwanted info from 
> the printOn:
>  
> a Prestamo fechaPrevistaDevolucion: 20 January 2013 fechaPrestamo: 17 January 
> 2013 id: ''1'' idSocio: ''2'' idEjemplarl: ''1'' fechaDevolucion: '
>  
> Where I want:
>  
> 20 January 2013 17 January 2013 1 2 1 ''
>  
> Here you can find the source code:
> https://github.com/arguser/Paradigmas-Final

Re: [Pharo-project] Must OSPlatform class>>osVersion be deprecated?

[Marcus Denker]

On Jan 22, 2013, at 11:55 PM, David T. Lewis  wrote:

> On Tue, Jan 22, 2013 at 01:51:56PM -0800, Chris Cunningham wrote:
>> On Tue, Jan 22, 2013 at 12:13 PM, David T. Lewis wrote:
>> 
>>> On Tue, Jan 22, 2013 at 08:05:02PM +0100, Marcus Denker wrote:
 
 On Jan 22, 2013, at 5:27 PM, H. Hirzel  wrote:
 
> Dave
>> 
 This works in Pharo 2.0?
>>> 
>>> Yes, "Smalltalk os version" is right for Pharo 2.0.
>>> 
>>> I'm looking for a way to modify the following method so that it adds
>>> support
>>> for Pharo 2.0, so that it continues to work in the other images, and so
>>> that
>>> it does not raise deprecation warnings or DNUs in any of the images.
>>> 
>> 
>> Could you capture for deprecation of OSPlatform osVersion, and resend the
>> other method (Smalltalk osVersion current osVersion)?  Or, trap for
>> Deprecation and resume it (ignore deprecation - once it is removed, you'll
>> automatically fail-over to the new code).
> 
> No, Pharo 2.0 is writing console output whenever an exception occurs, so
> catching the exception is not good. But not raising the exception in the
> first place works just fine ;)
> 
I will un-deprecate the osVersion methods in 2.0 and mark it as compatibility.

Marcus

Re: [Pharo-project] DocTest

[Nicolas Cellier]

Who should assert then?
>From a certain POV, it does not seem that awfully unlogical to
delegate this responsability to a TestCase.
A TestCase is here to assert some rule.

Nicolas

2013/1/23 Camillo Bruni :
> for that we already have a fully working Phexample:
>
> http://www.squeaksource.com/phexample.html
>
> which I will push in 3.0, cause I never really liked #assert: and friends 
> being
> sent to self. Furthermore we could finally build up decent messages!
>
> On 2013-01-22, at 18:24, Stéphane Ducasse  wrote:
>
>> it would be nice to introduce the same syntax than Sunit
>>
>>   exp assert: exp2
>>
>>   [ exp ] shouldraise:
>>
>> Stef
>>
>>
>> On Jan 21, 2013, at 4:41 AM, Benjamin wrote:
>>
>>> Hi guys,
>>>
>>> I am attending a python lecture and discovered DocTest[1], and I was 
>>> wondering if such a tool exists for Pharo ? :)
>>>
>>>
>>> Ben
>>>
>>> [1]http://docs.python.org/2/library/doctest.html
>>>
>>>
>>
>>
>
>

Re: [Pharo-project] OrderedCollections and File I/O

[Esteban Lorenzano]

yep, fuel... :)

On Jan 23, 2013, at 6:50 AM, Dennis Schetinin  wrote:

> Fuel: http://rmod.lille.inria.fr/web/pier/software/Fuel
> 
> 
> Best regards,
> Dennis Schetinin
> 
> On Wednesday, 23 January 2013 г. at 8:24, J. P. L. Martín wrote:
> 
>> Say I have an OrderedCollection which I want to save into a file and then 
>> recover from that file when I restart the application. How should I proceed? 
>> So far I've been doing a mess, saving the OrderedCollection on a file 
>> asString, since I'm then unable to recover it asOrderedCollection.
>> 
>> Another problem that I have is at the moment of showing items from that 
>> OrderedCollection on a MultiColumnListMorph where I get unwanted info from 
>> the printOn:
>> 
>> a Prestamo fechaPrevistaDevolucion: 20 January 2013 fechaPrestamo: 17 
>> January 2013 id: ''1'' idSocio: ''2'' idEjemplarl: ''1'' fechaDevolucion: 
>> '
>> 
>> Where I want:
>> 
>> 20 January 2013 17 January 2013 1 2 1 ''
>> 
>> Here you can find the source code:
>> https://github.com/arguser/Paradigmas-Final
> 

Re: [Pharo-project] OrderedCollections and File I/O

[Sven Van Caekenberghe]

On 23 Jan 2013, at 05:24, J. P. L. Martín  wrote:

> Say I have an OrderedCollection which I want to save into a file and then 
> recover from that file when I restart the application. How should I proceed? 
> So far I've been doing a mess, saving the OrderedCollection on a file 
> asString, since I'm then unable to recover it asOrderedCollection.
> 
> Another problem that I have is at the moment of showing items from that 
> OrderedCollection on a MultiColumnListMorph where I get unwanted info from 
> the printOn:
> 
> a Prestamo fechaPrevistaDevolucion: 20 January 2013 fechaPrestamo: 17 January 
> 2013 id: ''1'' idSocio: ''2'' idEjemplarl: ''1'' fechaDevolucion: '
> 
> Where I want:
> 
> 20 January 2013 17 January 2013 1 2 1 ''
> 
> Here you can find the source code:
> https://github.com/arguser/Paradigmas-Final

Fuel is a fast binary serializer that can store almost anything.

If the collection is holding clean domain level objects, you could also use 
XML, JSON or STON.
These give you human readable textual representations.

Sven

Search for
XML Support
NeoJSON
STON

--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill

[Pharo-project] [update 2.0] #20483

[Marcus Denker]

20483
-

Issue 7305: Adding username/password support to 
ConfigurationCommandLineHandler>>gofer  
http://code.google.com/p/pharo/issues/detail?id=7305

Issue 7302: the emergency evaluator revert functionality does not work
http://code.google.com/p/pharo/issues/detail?id=7302

Issue 7300: PreDebugWindow has two unused instance variables
http://code.google.com/p/pharo/issues/detail?id=7300


Diff information:
http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1014.diff
http://ss3.gemstone.com/ss/Pharo20/ConfigurationCommandLineHandler-Core-MarcusDenker.8.diff