[Pharo-project] [OT] Nice simulation
Sorry for the off-topic, but the lighthouse in the beginning of* this videohttp://youtu.be/F5KuP6qEuew * was just too nice not to share :-) -- Cheers,
Re: [Pharo-project] help needed
On 31 jan 2013, at 01:04, Stéphane Ducasse stephane.duca...@inria.fr wrote: Arghh What a terrible method……. so ugly. There is something fundamentally wrong. +1000 -- Cheers, Peter This is why we should rewrite MorphTreeMorph. Stef On Jan 30, 2013, at 4:13 PM, Usman Bhatti wrote: I am trying to look into this issue in Glamour related to morphs: http://code.google.com/p/pharo/issues/detail?id=7345 The problem is that, in Glamour, one can choose to display first few items instead of the all and then the user can choose to display more. When the selection is set to the items not shown, there is a DNU in PaginatedMorphTreeMorph. Digging this problem, I have encountered this piece of code for which I would require the help of someone knowing Morph. Is someone knowledgable about this piece of code? Here you can find an image with the script to explore the problem: https://dl.dropbox.com/u/11804892/glamour-treemorphs.zip MorphTreeMorph update: update: aSymbol aSymbol == #selection ifTrue: [^ self listManager updateSelectionFromModel]. ((aSymbol isKindOf: Array)and: [aSymbol size 1 and: [aSymbol first == #selectItems and: [aSymbol second isCollection]]]) ifTrue: [^ self selectedItems: aSymbol second]. aSymbol == self nodeListSelector ifTrue: [^ self updateList]. aSymbol == #selectAll ifTrue: [^ self listManager selectAll]. aSymbol == #deselectAll ifTrue: [^ self listManager deselectAll]. ((aSymbol isKindOf: Array) and: [aSymbol size 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #openPath]]]) allow directed path opening where multiple trees exist ifTrue: [^(self allNodeMorphs at: 1 ifAbsent: [^self]) openPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol size 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #openItemPath]]]) allow directed path opening where multiple trees exist ifTrue: [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) openItemPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol size 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #expandAllFromNode:]]]) ifTrue: [^ self expandAllFromNode: aSymbol third]. ((aSymbol isKindOf: Array) and: [aSymbol size 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #closeItemPath]]]) allow directed path closing where multiple trees exist ifTrue: [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) closeItemPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol notEmpty and: [aSymbol first == #openPath]]) ifTrue: [^(self allNodeMorphs at: 1 ifAbsent: [^self]) openPath: aSymbol allButFirst]. ((aSymbol isKindOf: Array) and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector and: [ aSymbol second == #expandRoots]]]) ifTrue: [^self expandRoots]. ((aSymbol isKindOf: Array) and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector]]) ifTrue: [aSymbol second = #expandAll ifTrue: [^ self expandAll]. aSymbol second = #collapseAll ifTrue: [^ self collapseAll]]
Re: [Pharo-project] UITheme builder, change newList list onButtonClick
Quick question: what's with all the curly braces? This doesn't look much like
Smalltalk code to me :-P
--
Cheers,
Peter.
On 2 jan 2013, at 10:02, J. P. L. Martín argu...@gmail.com wrote:
Hello, I'm having trouble to figure out how to do this, I have a simple
window with 3 buttons, each button should change the content listed on the
list below them but I'm really not sure about how to do it.
This is the code for the window:
---
open
Abre la ventana principal del Sistema de Gestion Bibleotecaria
| builder contain |
builder := UITheme builder.
contain := builder newColumn: {builder newRow: {
builder newButtonFor: self action: #onPrestamosClick label:
'Prestamos' help: ''.
builder newButtonFor: self action: #onMaterialesClick label:
'Materiales' help: ''.
builder newButtonFor: self action: #onSociosClick label: 'Socios'
help: ''}.
builder newColumn: {
builder newListFor: self list: nil selected: nil changeSelected:
nil help: '' }.}.
(contain openInWindowLabeled: 'Babel') extent: 600@600.
---
How should I define #onLabelClick to set the list to for example: Prestamo
database.
Thanks in advance.
Re: [Pharo-project] UITheme builder, change newList list onButtonClick
I wasn't being ironic, I just didn't know. In my 18 years of Smalltalk
programming, I've managed to avoid coming across that particular syntax before.
Is it Pharo-specific?
--
Cheers,
Peter.
On 2 jan 2013, at 10:12, Frank Shearar frank.shea...@gmail.com wrote:
On 2 January 2013 09:09, Peter Hugosson-Miller oldmanl...@gmail.com wrote:
Quick question: what's with all the curly braces? This doesn't look much
like Smalltalk code to me :-P
I don't know how much this is tongue-in-cheek: assuming none ( :) ),
it's a literal Array assembled by sending messages, as opposed to the
other kind of literal Array: #(1 (2 3)) = Array with: 1 with: (Array
with: 2 with: 3).
frank
--
Cheers,
Peter.
On 2 jan 2013, at 10:02, J. P. L. Martín argu...@gmail.com wrote:
Hello, I'm having trouble to figure out how to do this, I have a simple
window with 3 buttons, each button should change the content listed on the
list below them but I'm really not sure about how to do it.
This is the code for the window:
---
open
Abre la ventana principal del Sistema de Gestion Bibleotecaria
| builder contain |
builder := UITheme builder.
contain := builder newColumn: {builder newRow: {
builder newButtonFor: self action: #onPrestamosClick label:
'Prestamos' help: ''.
builder newButtonFor: self action: #onMaterialesClick label:
'Materiales' help: ''.
builder newButtonFor: self action: #onSociosClick label:
'Socios' help: ''}.
builder newColumn: {
builder newListFor: self list: nil selected: nil
changeSelected: nil help: '' }.}.
(contain openInWindowLabeled: 'Babel') extent: 600@600.
---
How should I define #onLabelClick to set the list to for example: Prestamo
database.
Thanks in advance.
Re: [Pharo-project] UITheme builder, change newList list onButtonClick
Guess it's a bit like the ##(some expression here) of VisualAge Smalltalk? -- Cheers, Peter. On 2 jan 2013, at 10:27, Marcus Denker marcus.den...@inria.fr wrote: On Jan 2, 2013, at 10:25 AM, Peter Hugosson-Miller oldmanl...@gmail.com wrote: I wasn't being ironic, I just didn't know. In my 18 years of Smalltalk programming, I've managed to avoid coming across that particular syntax before. Is it Pharo-specific? It was introduced in Squeak quite early (before 2000). Marcus
Re: [Pharo-project] UITheme builder, change newList list onButtonClick
Sorry for hijacking the thread, I just wanted to be sure I understood it properly. So now I think it's a kind of syntactical sugar for a nicer way of writing: Array with: (builder newButtonFor: self action: #onPrestamosClick label: 'Prestamos' help: '') with: (builder newButtonFor: self action: #onMaterialesClick label: 'Materiales' help: '') with: (builder newButtonFor: self action: #onSociosClick label: 'Socios' help: '') Does that sound like a good explanation? -- Cheers, Peter On Wed, Jan 2, 2013 at 11:15 AM, Frank Shearar frank.shea...@gmail.comwrote: On 2 January 2013 09:52, Peter Hugosson-Miller oldmanl...@gmail.com wrote: Guess it's a bit like the ##(some expression here) of VisualAge Smalltalk? I think so, but I've only seen ##(foo) in GNU Smalltalk, where it's a compile-time literal: http://www.gnu.org/software/smalltalk/manual/gst.html frank -- Cheers, Peter. On 2 jan 2013, at 10:27, Marcus Denker marcus.den...@inria.fr wrote: On Jan 2, 2013, at 10:25 AM, Peter Hugosson-Miller oldmanl...@gmail.com wrote: I wasn't being ironic, I just didn't know. In my 18 years of Smalltalk programming, I've managed to avoid coming across that particular syntax before. Is it Pharo-specific? It was introduced in Squeak quite early (before 2000). Marcus
Re: [Pharo-project] About RBLiteralArrayContainsCommaRule
Possibly it's useful as a warning to one who comes from a C-syntax language, and might accidentally define a literal array containing some. For example, #(1, 2, 3) - not an error, but not (as the perpetrator might believe) an array containing three integers ;) -- Cheers, Peter. On 30 dec 2012, at 20:48, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I'm going over all the SmallLint rule and extending their rationale and fixing sometimes their default check. Now I'm reading RBLiteralArrayContainsCommaRule rationale ^ 'Checks for literal arrays that contain the #, symbol.' and I have no idea why this would be a problem. Anybody has an idea? Stef
Re: [Pharo-project] Nautilus and grey out text
On 12 dec 2012, at 11:52, Sven Van Caekenberghe s...@stfx.eu wrote: On 12 Dec 2012, at 11:20, dimitris chloupis theki...@yahoo.co.uk wrote: ok I understand now thank you all for the clarifications. Very exciting and powerful stuff, the more I learn about pharo and smalltalk the more I love it. Yes, Dimitris, that is the idea. But you have been warned: once you get infected it is hard to go back ;-) That was the understatement of the year: I went from using Smalltalk in my daily job for 15 years, to Java. Two years later and not a day goes by that I don't wish I could have carried on using Smalltalk! How long does it take for the infection to be cured, anyone know? -- Cheers, Peter. One other thing: there is a Pharo-Users mailing list as well, it has less traffic, but the idea is that conversations like the one in this thread (how do I do this or that ? what does this or that mean ?) are better held there. http://www.pharo-project.org/community Keep on asking questions ! From: Esteban Lorenzano esteba...@gmail.com To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis theki...@yahoo.co.uk Sent: Wednesday, 12 December 2012, 12:15 Subject: Re: [Pharo-project] Nautilus and grey out text No, just a method added to a class, and categorized with a special name: *NameOfThePackageWhereItBelongs Esteban On Dec 12, 2012, at 11:11 AM, dimitris chloupis theki...@yahoo.co.uk wrote: Oh I see, very clever, are those methods traits ? From: Pavel Krivanek pavel.kriva...@gmail.com To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis theki...@yahoo.co.uk Sent: Wednesday, 12 December 2012, 11:48 Subject: Re: [Pharo-project] Nautilus and grey out text If you have got a package named MyPackage then if some class that is not part of this package has got some methods in categories named like *MyPackage(-Something) (star, package name, optional category) then this methods are bundled together with MyPackage. -- Pavel On Wed, Dec 12, 2012 at 10:38 AM, dimitris chloupis theki...@yahoo.co.uk wrote: thanks added to my list of things to study :) From: Sven Van Caekenberghe s...@stfx.eu To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis theki...@yahoo.co.uk Sent: Wednesday, 12 December 2012, 11:33 Subject: Re: [Pharo-project] Nautilus and grey out text On 12 Dec 2012, at 10:25, dimitris chloupis theki...@yahoo.co.uk wrote: Thanks for the reply , by extension you mean inheritance ? Package A class subclasses package B class ? No, it is extension with respect to Monticello/RPackage packaging. From: Pavel Krivanek pavel.kriva...@gmail.com To: Pharo-project@lists.gforge.inria.fr; dimitris chloupis theki...@yahoo.co.uk Sent: Wednesday, 12 December 2012, 11:19 Subject: Re: [Pharo-project] Nautilus and grey out text If a package A adds an exteinson to a class from different package B then the extended class from package B is grayed out and all methods that are not part of the package A too. -- Pavel On Wed, Dec 12, 2012 at 10:03 AM, dimitris chloupis theki...@yahoo.co.uk wrote: I went through the Nautilus pdf and it seems to explains most of the thing but the grey out text. Any idea why some classess and methods are grey out ? By the way congratulation to Nautilus author and all people contributing to it , it certainly looks like a big improvement over the classic system browser. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Re: [Pharo-project] Vim Keys?
+1 -- Cheers, Peter. On 30 nov 2012, at 19:13, Igor Stasenko siguc...@gmail.com wrote: On 30 November 2012 18:23, ☈king rkingd...@sharpsaw.org wrote: On 11/30/2012 10:48 AM, Marcus Denker wrote: I am sure the Emacs user will be violently against it. Actually, that's the thing: Namespacing. You could install vi keys on emacs and an emacs user would never notice without hitting the Escape key. Emacs keys, on the other hand, *do* conflict with existing Pharo bindings. Another thing is that I personally think that one of the things that Smalltalk did very early is to not have modes for editing… Are editing modes really something people want in 2012? Think of modes as a monkey that sits by your keyboard. Every time you bop him on the head (that is, you hit Escape), he obediently reaches over and holds down a special keyboard modifier for you, and continues to do so until you tell him to stop. Since bopping him on the head takes no more time than hitting the modifier key itself, hitting [Bop],[Key] is always going to be an equally concise way of entering a string of commands compared to chording [Modifier+Key]. But generally it's more concise, because you tend to do big sequences of one or the other: edit a bunch, or input a bunch. That is, in real life you do [Bop],[Key],[Key2],[Key],[Key3], which is better than [Modifier1+Key],[Modifier2+Key2],[Modifier1+Key],[Ctrl+Alt+Shift+Modifier+TurboDrive+Footpedal+☝+Key3] well, what you explaining here is not just about handling keyboard typing, but also requires changes in UI (showing command line, black white color scheme, 80x25 text mode ;) ) etc.. i think, if vi would contest for best obscure editor, i guess it would get 1st prize. i don't really care why you like it , just can you (or someone else) explain me, why you think it is best possible way of doing things? Since i can't see it. What exactly commands/shortcuts you wanna have there? And wouldn't it be better to focus UI design towards avoiding the need for shortcuts/modes alltogether? Also, i going to repeat same over again: we don't need a full-fledged text editor(s) in smalltalk IDE. In smalltalk you will find yourself rarely need to edit more than 10 lines of code at time. From that perspective, do you think it is wise to invest people's energy into that? I think it should be a call for those who miss it: if you want it - make it. After all, you can run vi/emacs/put your favorite in separate window, and can always copy-paste text between, and enjoy your lovely keyboard shortcuts. Sorry, maybe i miss something and don't see full picture, but i really don't understand what is so cool in having vi/emacs shortcuts in pharo.. The critical point is that users that don't enter command mode would never be bothered by it. Users who do stumble upon it could get an additional leg up with the help text, and they don't even really have to know it's Vi Keys, just that it's a non-chorded interface. I know it's radical, but that's how we roll. (Right?) —☈ -- Best regards, Igor Stasenko.
Re: [Pharo-project] about sharing class binding and others
On Sun, Nov 18, 2012 at 10:40 PM, James Foster smallt...@jgfoster.netwrote: I don't see the benefit of the added complexity. As it is now, at compile time the reference is not bound to a global but to an Association holding the global. If you want to change the value of the global you can do so and the method will reference the new value. Also, if you want to do name-lookup at runtime you can explicitly code it to do that. My objection to always doing run-time name lookup is that I would like to be able to create a module that is self-contained and binds to the the classes I provide without risking that someone else will replace my classes. I would like you to be able to load my module, containing my classes and methods, and we both can be confident that your later changes (including different classes with the same name) will not impact my classes and methods. If you want a parameterized module, then the module should be explicitly coded to take a parameter and use it explicitly. I think it is not as clear to let the module think it is referencing a Point but in fact play a trick on it to have it reference a different class. - James On Nov 16, 2012, at 6:17 PM, Stéphane Ducasse wrote: While I love the idea of sharing the systemDictionary class binding in the method to gain immediate update in case of change I was questioning myself if we could not gain from not having (for example to get parametrized modules). The point is that we are not constantly changing classes especially when not programming but running program. So let us do some experiments: CompiledMethod allInstances size 58891 (CompiledMethod allInstances select: [:each | each classBinding value name = #Point]) size 100 [CompiledMethod allInstances select: [:each | each classBinding value name = #Point]] timeToRun 23 this is the best case since classBinding is at a fixed size now looking for any reference to Point (CompiledMethod allInstances select: [:cm | cm literals anySatisfy: [:each | each class = Association and: [each key = #Point ]]]) size 134 methods. [CompiledMethod allInstances select: [:cm | cm literals anySatisfy: [:each | each class = Association and: [each key = #Point timeToRun 91 ms so it looks to me that this sharing is not something that we should not changed if needed. What do you think? Stef +1 -- Cheers, Peter
Re: [Pharo-project] instVarNames vs instVarNamed:
This is weird, I'm not seeing the problem at all!
I've always thought of *#instVarNamed:* as a sibling method to
*#instVarAt:*(which maybe is more obviously an instance method). So
*anAddress instVarNamed: 'street'* would return a Street, just as *anAddress
instVarAt: 2* could. But anAddress, being just an instance, doesn't need to
know about its class definition directly, since it can always ask its class
if it needs to, so for example *anAddress class instVarNames* would return
the names of all the instance variables defined in the Address class.
Now can someone please explain why that is confusing?
--
Cheers,
Peter
On Sun, Sep 23, 2012 at 10:59 PM, Mariano Martinez Peck
marianop...@gmail.com wrote:
On Sun, Sep 23, 2012 at 6:55 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
since groups is an instance variable on the class side
Nautilus class instVarNames
- #('maxSize' 'cachedLastClasses' 'groups')
ok we get the instance variables
so it was strange that the class could not find the instance variable
using instVarNamed:
Nautilus class instVarNamed: 'groups'
- error
I was confused.
Looks strange to me as well. I would like that it actually works :)
Stef
On Sep 23, 2012, at 5:42 PM, Camillo Bruni wrote:
On 2012-09-23, at 17:38, Benjamin benjamin.vanryseghem.ph...@gmail.com
wrote:
On a class, should answer the inst of the corresponding metaclass
Like when you ask the inst var of an instance, you get the inst var of
the corresponding class
Ben
but that works, I don't get it :D
Nautilus instVarNamed: #maxSize
Nautilus new instVarNamed: #announcer
and:
Nautilus class instVarNames includes: #maxSize.
Nautilus instVarNames includes: #announcer.
everything fine and symmetrical here...
--
Mariano
http://marianopeck.wordpress.com
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
Hej Hilaire! I've bought the paid version, and it does look pretty nice. As you ask for feedback, I thought it would be OK to post it here, apologies to all if it's not appropriate! Never having seen the app before, I was unable to find a help or tutorial button within my personal frustration time. May I suggest that first-time users be started up in some kind of newbie mode? I wanted to show this to my kids to demonstrate what amazing things are possible with Smalltalk, but for that to work I'd need to at least seem to understand it myself ;-) -- Cheers, Peter. On 16 sep 2012, at 10:30, Hilaire Fernandes hilaire.fernan...@edu.ge.ch wrote: Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It comes in two versions: gratis and paid. http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=frls=1mt=8 Compare to the desktop versions, it is almost feature complete: only the script and programmed figure can not be created or edited with this version. However, sketches including scripts are interpreted and rendered correctly on the tablet. *Feedbacks* and *rating* are welcome and greatly appreciated! Thanks! http://drgeo.eu
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
Yes, I think that a beginners video channel would be a great idea! When I get to the stage of understanding things enough, maybe I'll be able to help. I have English as my mother tongue, and my sister is French, and speaks excellent English. I'm not promising anything, but it does feel important to me at the moment ;-) -- Cheers, Peter. On 16 sep 2012, at 12:14, Hilaire Fernandes hilaire.fernan...@edu.ge.ch wrote: Hi Peter, Interactive geometry software are very specilised software, so you need to understand how it works. Tutorial are indeed important. My main problem is speaking language. I have written documentation in French at http://www.drgeo.eu/screenshot-video I can't produce an english documentation with a good quality level. We have some video tutorial at http://www.drgeo.eu/screenshot-video Some of the video are in French other in English But I should set up a Video channel for begginer to get started, it will be a great idea. What do you think? Next about tutorial button within DrGeo, yes it will be a nice addition. It is someting I need to thing about. Thanks for your feedback Hilaire Le 16/09/2012 11:53, Peter Hugosson-Miller a écrit : Hej Hilaire! I've bought the paid version, and it does look pretty nice. As you ask for feedback, I thought it would be OK to post it here, apologies to all if it's not appropriate! Never having seen the app before, I was unable to find a help or tutorial button within my personal frustration time. May I suggest that first-time users be started up in some kind of newbie mode? I wanted to show this to my kids to demonstrate what amazing things are possible with Smalltalk, but for that to work I'd need to at least seem to understand it myself ;-) -- Cheers, Peter. On 16 sep 2012, at 10:30, Hilaire Fernandes hilaire.fernan...@edu.ge.ch wrote: Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It comes in two versions: gratis and paid. http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=frls=1mt=8 Compare to the desktop versions, it is almost feature complete: only the script and programmed figure can not be created or edited with this version. However, sketches including scripts are interpreted and rendered correctly on the tablet. *Feedbacks* and *rating* are welcome and greatly appreciated! Thanks! http://drgeo.eu
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
Hehe, AFAIK, frustration time isn't a proper phrase, it's just something I made up to try and describe the time it takes from starting up a new program I've never seen before, until it makes me frustrated. In the best of cases that never happens, and I must say that it's highly personal, and depends largely on my expectations at the time. In this case, I had already decided to buy the app, not knowing if I would have a use for it, just because I like to do things to help the Smalltalk community in any way that I can. In the back of my mind I also hoped it might be something I could use with my kids, to show them a bit about geometry, maths in general, and maybe even Smalltalk. I was not expecting a beautiful, polished finish, nor much in the way of documentation, but I'd hoped that, given a few minutes of time, there would be enough clues to be found by clicking and prodding around, to be able to make it do something cool. Sadly, during the time I had available during that first look, I didn't manage to make anything happen at all, and I felt frustrated. I fear that someone with higher expectations might have become cross at that point, and that's why I wanted to suggest a tutorial button. Now I know that I just need to go and watch those demo videos before I try next time :-) Good luck! -- Cheers, Peter On Sun, Sep 16, 2012 at 5:01 PM, Hilaire Fernandes hilaire.fernan...@edu.ge.ch wrote: Peter, It will be terribly useful if you describe me where you get your frustration time. Thanks Hilaire Le 16/09/2012 11:53, Peter Hugosson-Miller a écrit : Never having seen the app before, I was unable to find a help or tutorial button within my personal frustration time. May I suggest that first-time users be started up in some kind of newbie mode?
Re: [Pharo-project] [NativeBoost] Question: zero-based or one-based indexes?
+1 to calling the 0-based stuff *offset*
/Peter
On Mon, Sep 3, 2012 at 12:02 PM, Igor Stasenko siguc...@gmail.com wrote:
ok. so i shall convert them all to 0-based.
and then carefully look over the code and get rid of 1-based assumption.
On 3 September 2012 11:58, Luc Fabresse luc.fabre...@gmail.com wrote:
Hi Igor,
I am also used to the 0-based when dealing with C-stuff.
Cheers,
#Luc
2012/9/3 Marten Feldtmann mar...@schrievkrom.de
Hello Igor,
0-based - because it's oriented towards C structures (and therefore
memory
oriented).
Another way to see this is: it's not an index, its an byte-offset from
the
beginning of the memory. Therefore I would not name the parameter as
something like index, but more like zeroBasedOffset. By the way:
VASmalltalk
does it the same way.
The same problem might occur, when dealing with pointers to array of
primitive data types in ByteArray or instances of NBExternalAddress.
Even here I would suggest using zero based index structures - though it
is
contrary to Smalltalk typical 0ne-based array index. In VASmalltalk this
situation is zero-based access and the parameter is not a byte index,
but a
data element index. And an index of 0 returns the start of the array
(and
the first element).
Marten
Am 03.09.2012 02:28, schrieb Igor Stasenko:
Hi, there
i added a bunch of accessors to ByteArray and NBExternalAddress which
having uniform look:
nbtypeAt:
nbtypeAt: put:
where types are:
{U}Int8/16/32/64
or
Float32/64
the problem is that indexes in ByteArray are 1-based,
but in NBExternalAddress is 0-based.
And there's already different places in code which following these
rules.
But i feel like this should be uniform (so same piece of code can be
used for either bytearrays or external addresses),
to avoid confusion and mistakes.
i just not sure which one to leave: 1-based or 0-based ?
From one side, all collections in smalltalk is 1-based..
but from other side accessing memory at 1-based offset looks also
unnatural.
What you think?
--
Best regards,
Igor Stasenko.
Re: [Pharo-project] On the frontpage of news.ycombinator.com
I tried, but it wouldn't let me log in, and I couldn't see any way of fixing that. Maybe I'll have better luck from a real computer later. -- Cheers, Peter. On 8 jul 2012, at 12:12, Sven Van Caekenberghe s...@beta9.be wrote: Super! I just voted it up. On 08 Jul 2012, at 08:23, Marcus Denker wrote: http://news.ycombinator.com/ Sunday morning... but nevertheless :-) Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] zip bug [IMPORTANT] probably related to the recent Zip changes
On Mon, Jun 11, 2012 at 2:58 AM, Sean P. DeNigris s...@clipperadams.comwrote: ... If that's the case, maybe wrap the unzip with a check that defaults to the old format if the date is invalid or strange (e.g. year 1962)... What's strange about 1962? I happen to think it's a rather nice year ;-) -- Cheers, Peter
Re: [Pharo-project] Jenkins status icons
The only coloured icons I've ever seen Jenkins produce are blue, yellow, red and grey, blue being all clear and grey disabled. I thought that was the standard, but I could be wrong... -- Cheers, Peter. On 2 maj 2012, at 21:32, Sean P. DeNigris s...@clipperadams.com wrote: How do you get the icon to turn green on a successful build? Jenkins is picking up my test report and showing 0 failures, but the icon is blue instead of green. Thanks, Sean -- View this message in context: http://forum.world.st/Jenkins-status-icons-tp4604223.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] [ANN] PharoLauncher for Mac users
Bookmarking this for when I get Lion on my personal MBP. It's still stuck on Snow Leopard for now :-( But this looks _really_ interesting, great job! /Peter On Tue, Apr 24, 2012 at 12:29 PM, HwaJong Oh daliot...@gmail.com wrote: Simple. I want to use Autolayout feature, which requires Lion(Mac OS X 10.7). :-) It is such a magic. Morphic may be great with it. HwaJong Oh -- View this message in context: http://forum.world.st/ANN-PharoLauncher-for-Mac-users-tp4580756p4582996.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Poll: What's Your Favorite Programming Language? | Hacker News
Done! -- Cheers, Peter On Sat, Mar 24, 2012 at 9:22 AM, Sven Van Caekenberghe s...@beta9.bewrote: Vote for Smalltalk! http://news.ycombinator.com/item?id=3746692 Registration is non-agressive.
Re: [Pharo-project] Enjoyed the reading..
Brilliant! I shared this on Facebook this morning, and three of my nerdy friends have then shared it further, so there's a lot in that article that hits home. Many thanks for the link! -- Cheers, Peter On Sat, Mar 10, 2012 at 10:37 AM, Ben Coman b...@openinworld.com wrote: Off topic... but the following article by Paul Graham has been one of my all time favorites for the last few years... http://www.paulgraham.com/**nerds.htmlhttp://www.paulgraham.com/nerds.html
Re: [Pharo-project] Do not feed the trolls
Nice try, Dale, but this troll will apparently eat anything - even Wikipedia articles :-p -- Cheers, Peter.
Re: [Pharo-project] Are Objects really hard?
On Wed, Feb 15, 2012 at 9:50 AM, Marcus Denker marcus.den...@inria.frwrote: It is much more interesting to google Guido Stepken Troll Just have a look: http://www.google.com/search?ls=enq=%22Guido+Stepken%22+Troll Wow! About 1,030 results, that's pretty impressive. Should we be honoured to have such a celebrity visiting us? -- Cheers, Peter
Re: [Pharo-project] Are Objects really hard?
Hey Guido, I thought you said you were leaving us! Just too hard to stay away, eh? :-) -- Cheers, Peter On Mon, Feb 13, 2012 at 5:25 PM, Guido Stepken gstep...@googlemail.comwrote: Hahaha! You are running Apache Server in Front, caching all I/O, leaving no load for Pharo at all, serving static webpages even. Tnx 4 your funny comment! Have fun, Guido Stepken Am 13.02.2012 17:08 schrieb Sven Van Caekenberghe s...@beta9.be: On 13 Feb 2012, at 16:32, Guido Stepken wrote: Its quite difficult not to say *impossible* to run Pharo even for simple tasks within a small vserver account with 256 or 512 MB reserved or dynamically assigned memory space. This is ridiculous: a current stock Pharo server image (i.e. non-stripped) compares favorably with any other dynamic language. http://zn.stfx.eu/zn/index.html#livedemo I am currently running 5 VM's on an AWS EC2 micro instance (613MB RAM, up to 2 ECU (1 ECU = the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor)). Setup can also be quite simple: http://forum.world.st/Pharo-Core-HTTP-Server-OneCommandLine-Demo-td3702218.html#a3702245 Sven
Re: [Pharo-project] Boolean Logic
Because to calculate the result, the block must always be evaluated, so it's a bit redundant. -- Cheers, Peter. On 2 feb 2012, at 17:08, Robert Sirois watchl...@hotmail.com wrote: Ok, this may be from a simple lack of understanding, but I just have to know ;) Why can I call #or: (Boolean and friends) with a block, but #xor: only takes a Boolean? I would think the paradigm would remain the same and be able to compose operators like #or:, etc.? What am I missing? Thanks! RS
Re: [Pharo-project] Misc. newbie questions
On 6 jan 2012, at 06:41, Gerry Weaver ger...@compvia.com wrote: 2. There appear to be some tool choices in the Pharo image. I would like to be able to create a class and it's methods in an editor in one go. I like being able to see all of the class code at once. Is there a way to do this? I just want to be able to type it all in and accept (evaluate?) all at once. This is an interesting question to me personally. After 15 years of working exclusively in Smalltalk I've recently been forced to start programming in Java, where the source code is always (as far as I know) arranged in the way you describe. This organization just emphasizes the dead and compiled nature of Java (and similar languages), compared to the living objects of Smalltalk, where even methods are objects, created by sending messages to other objects. Source code is relegated to being a mere artifact, which can be saved and organized in any way one wishes, and preferably never shows its ugly face to the coder :-p So my advice is, count yourself lucky that you have the chance to enter the world of real, pure, objects. Go with the flow, let your old idioms and practices go, and have fun! My Smalltalk years were the best time in my professional life, and I am quite envious of anyone that still gets to use Smalltalk professionally. And yes, I really *really* miss a good, object oriented class browser! -- Cheers, Peter
Re: [Pharo-project] Slow text input?
I think the troll said he was leaving, so let's just all take a deep breath, be thankful for that, and move on. Positive energy is what we need here, feeding trolls drains us more than one would think, so as far as possible we should just try and ignore them. Carlo's answer was cool, too ;-) -- Cheers, Peter On Tue, Nov 15, 2011 at 1:26 PM, Igor Stasenko siguc...@gmail.com wrote: Currently, my Mac running 3 images. And it is hard to tell, but i think one of them runs maybe more than month , without hangs, freezes etc. Now, why i should trust your words (not backed with anything serious) that the software i use is unstable, when i using it every day and it works well for me? On 15 November 2011 12:18, Guido Stepken gstep...@googlemail.com wrote: Ok, if it helps you to understand, that unstable software is quite useless for anybody ... will do that! Guido Stepken Am 15.11.2011 um 12:05 schrieb Marcus Denker marcus.den...@inria.fr: On Nov 15, 2011, at 8:00 AM, Guido Stepken wrote: I think, programming, refactoring a peace of software has very much to do with model theory, Löwenheim-Skolem theory (related to fixed point theorem). Good programmers migrate code, addon's from one stable, consistent state to the other. These stable states are expressed in release numbers. What are you doing? Don't know! So why don't you then just unsubscribe from the mailinglist? We clearly are not up to your standards. And this will not change. I think there is no way that we can work constructively together, so the best for all is that you just go away. and everyone is happy. (you, too!) You can refactor according to Skolem, we refactor how we like it, and everyone is happy. Marcus -- Marcus Denker -- http://marcusdenker.de -- Best regards, Igor Stasenko.
Re: [Pharo-project] MAC OS upgrade and Pharo compatibility
Definitely do a backup, then format the disk and perform a clean install, then do all the necessary software updates until the machine is completely up to date. Finally restore your user settings and apps from the backup. That's my recipe for minimum frustration when dealing with Lion :-) -- Cheers, Peter On Sat, Nov 5, 2011 at 10:34 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: There is no problem for pharo on lion. Now do a backup because lion of your machine. Lion frustrated me a lot. And in general when I see the amount of applications spinning to death on normal usage, I think that pharo is doing well. Stef On Nov 5, 2011, at 8:09 PM, Dario Trussardi wrote: Hi, i'm interested to upgrade my MacBook Operating System, from Leopard to Lion version. I'm not expert about it and i will not do error. My question is about Pharo compatibility. Now i work with Pharo 1.0 #10517 and GemTools 1.0-beta.8.3. I need to do something or all work fine after upgrade the O/S ? Thanks, Dario P.S. Excuse me if question is not very very pertinent to Pharo
Re: [Pharo-project] MAC OS upgrade and Pharo compatibility
No, Stef, I'm the same: bugs love me! I am sooo glad for the excellent backup program SuperDuper. I did the Lion install two times before it worked OK (third time just like I wrote in my post above), but the other two times I was very happy to have the backup to go back to, I can tell you! -- Cheers, Peter On Sat, Nov 5, 2011 at 10:56 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Yes because I could not update after the first install. So I was lucky to have another machine where I could install and update **then** migrate. I was mad during 3 days. Of course for everybody around it worked well but I attrack bugs. Stef On Nov 5, 2011, at 10:40 PM, Peter Hugosson-Miller wrote: Definitely do a backup, then format the disk and perform a clean install, then do all the necessary software updates until the machine is completely up to date. Finally restore your user settings and apps from the backup. That's my recipe for minimum frustration when dealing with Lion :-) -- Cheers, Peter On Sat, Nov 5, 2011 at 10:34 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: There is no problem for pharo on lion. Now do a backup because lion of your machine. Lion frustrated me a lot. And in general when I see the amount of applications spinning to death on normal usage, I think that pharo is doing well. Stef On Nov 5, 2011, at 8:09 PM, Dario Trussardi wrote: Hi, i'm interested to upgrade my MacBook Operating System, from Leopard to Lion version. I'm not expert about it and i will not do error. My question is about Pharo compatibility. Now i work with Pharo 1.0 #10517 and GemTools 1.0-beta.8.3. I need to do something or all work fine after upgrade the O/S ? Thanks, Dario P.S. Excuse me if question is not very very pertinent to Pharo
Re: [Pharo-project] scaled decimal question
Yeah, but the *big* difference is that asScaledDecimal: 2 is a message sent to a Float, whereas the s2 is just part of the literal representation of a ScaledDecimal, and *not* a message sent to anything. -- Cheers, Peter. On 18 sep 2011, at 17:59, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Sep 18, 2011, at 5:47 PM, Nicolas Cellier wrote: 2011/9/18 Stéphane Ducasse stephane.duca...@inria.fr: For me the problem is that if s2 means scaled decimal then I do not understand why asScaledDecimal produce objects with different properties. a number is a scaled decimal or not. There is a difference between these two: (1/10) asScaledDecimal: 2. (1/10) asFloat asScaledDecimal: 2. That I can understand Float is inexact. No problem with that. Now I do not understand how 0.1s2 relates to the above expressions. asFloat introduces a rounding error. Though the result prints 0.1, it is different from (1/10), asFrank said, just convert it back asTrueFraction, and you'll see. asScaledDecimal: does not undo the rounding error, it just uses asTrueFraction. If you want to undo the error, you may try (0.1 roundTo: 0.01s2). Nicolas On Sep 18, 2011, at 10:36 AM, Frank Shearar wrote: On 17 September 2011 14:06, Peter Hugosson-Miller oldmanl...@gmail.com wrote: Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. Sure I guessed that too but I hate this behavior. Indeed. In particular, the Floats turn themselves into exact representations (Float #asTrueFraction) - Fractions whose bit patterns duplicate the float representation. That means that the resulting ScaledDecimals (0.1s2 + 0.2s2 and 0.3s2) have differing fraction instvars. frank -- Cheers, Peter. On 17 sep 2011, at 15:01, Stéphane Ducasse stephane.duca...@inria.fr wrote: Why (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) returns false while 0.1s2 + 0.2s2 = 0.3s2 returns true ?
Re: [Pharo-project] scaled decimal question
Probably because Floats are not exact, so the result of #asScaledDecimal: when sent to a Float, differs from what the compiler produces when it parses 0.1s2. -- Cheers, Peter. On 17 sep 2011, at 15:01, Stéphane Ducasse stephane.duca...@inria.fr wrote: Why (0.1 asScaledDecimal: 2) + (0.2 asScaledDecimal: 2) = (0.3 asScaledDecimal: 2) returns false while 0.1s2 + 0.2s2 = 0.3s2 returns true ?
Re: [Pharo-project] Pharo One Click 1.3 LNK file
+100!! -- Cheers, Peter. On 14 sep 2011, at 08:31, Marcus Denker marcus.den...@inria.fr wrote: On Sep 14, 2011, at 8:28 AM, Sven Van Caekenberghe wrote: On 14 Sep 2011, at 08:19, Marcus Denker wrote: The One-Click here: https://gforge.inria.fr/frs/download.php/28922/Pharo-1.3-OneClick.zip Does not use a LNK File, it just has the exe in the main directory. And current VMs. (Yes, and the one click on the Build server is out of date... maybe we should remove it for now to have less confusion) Yeah, I saw that I had two different versions on my machine, not sure what the most recent was I followed the one on the page, http://www.pharo-project.org/pharo-download/release-1-3 to https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/lastSuccessfulBuild/artifact/PharoOneClick1.3.zip The one fresh of the build server should be the latest no ? That is using the LNK file though. Latest from the image yes. VMs: no. Yes, this is all confusing and needs to be fixed... and the whole Hudson build server needs to be discontinued, ASAP. (It's very confusing to have two. We are really good at doing very confusing things... we need to improve that). Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] String mathematical operations
+ '1' ;-) On Tue, Sep 6, 2011 at 4:18 PM, Lorenzo Schiavina lore...@edor.it wrote: + 1 - Original Message - From: Nicolas Cellier nicolas.cellier.aka.nice@**gmail.com nicolas.cellier.aka.n...@gmail.com To: Pharo-project@lists.gforge.**inria.frPharo-project@lists.gforge.inria.fr Sent: Tuesday, September 06, 2011 2:16 PM Subject: Re: [Pharo-project] String mathematical operations +1 2011/9/6 Igor Stasenko siguc...@gmail.com: personally, i prefer a strict-typing behavior when using arithmetics. for that reason, i prefer seeing error in someString + 4 or 4 + someString but not automagical conversion. On 6 September 2011 13:57, Camillo Bruni camillo.br...@inria.fr wrote: We still have a lot of awkward methods on String for doing math: String #* arg ^ arg adaptToString: self andSend: #* Who is relying on them? I would like to deprecate them all :D I guess some binary math selectors might make sense String #* count ^ self class new: self size * count streamContents: [ :stream| count timesRepeat: [ stream self ]]. cami -- Best regards, Igor Stasenko. -- Cheers, Peter
Re: [Pharo-project] I am petrified. I don't know what to say ........... (just look at that)
OMFG! :-((( -- Cheers, Peter. On 12 aug 2011, at 17:16, Max Leske maxle...@gmail.com wrote: Good luck with refactoring *that*… On 12.08.2011, at 17:12, Igor Stasenko wrote: DiskProxycomeFullyUpOnReload: smartRefStream Internalize myself into a fully alive object after raw loading from a DataStream. (See my class comment.) DataStream will substitute the object from this eval for the DiskProxy. | globalObj symbol arrayIndex | symbol := globalObjectName.See if class is mapped to another name (smartRefStream respondsTo: #renamed) ifTrue: [ If in outPointers in an ImageSegment, remember original class name. See mapClass:installIn:. Would be lost otherwise. (thisContext sender sender sender sender sender sender sender sender receiver class == ImageSegment and: [ thisContext sender sender sender sender method == (DataStream compiledMethodAt: #readArray) ]) ifTrue: [ arrayIndex := thisContext sender sender sender sender tempAt: 4.index var in readArray. Later safer to find i on stack of context. smartRefStream renamedConv at: arrayIndex put: symbol ]. save original name symbol := smartRefStream renamed at: symbol ifAbsent: [ symbol ] ].map globalObj := Smalltalk globals at: symbol ifAbsent: [ preSelector == nil (constructorSelector = #yourself) ifTrue: [ Transcript cr; show: symbol , ' is undeclared.'. (Undeclared includesKey: symbol) ifTrue: [ ^ Undeclared at: symbol ]. Undeclared at: symbol put: nil. ^ nil ]. ^ self error: 'Global ' , symbol , ' not found' ]. preSelector ifNotNil: [ Symbol hasInterned: preSelector ifTrue: [ :selector | [ globalObj := globalObj perform: selector ] on: Error do: [ :ex | ex messageText = 'key not found' ifTrue: [ ^ nil ]. ^ ex signal ] ] ].keep the Proxy if Project does not exist constructorSelector ifNil: [ ^ globalObj ]. Symbol hasInterned: constructorSelector ifTrue: [ :selector | [ ^ globalObj perform: selector withArguments: constructorArgs ] on: Error do: [ :ex | ex messageText = 'key not found' ifTrue: [ ^ nil ]. ^ ex signal ] ].args not checked against Renamed ^ nil -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Pharo 1.3 Seaside 'client' build ?
On Mon, Jul 25, 2011 at 4:31 PM, Sven Van Caekenberghe s...@beta9.bewrote: PS: Another questions is: is 1.3 'released', if so where are the links on the website, where is the 'noise' ? To paraphrase the famous quote: Pharo code is never released, it escapes! -- Cheers, Peter
Re: [Pharo-project] pharo on lion
+1000!!! -- Cheers, Peter. On 21 jul 2011, at 08:40, Lukas Renggli reng...@gmail.com wrote: Something for Esteban: it would be super cool if the VM had the full-screen button in the title bar :-) On Thursday, 21 July 2011, Lukas Renggli reng...@gmail.com wrote: It worked for me on the GM. On Thursday, 21 July 2011, Tudor Girba tu...@tudorgirba.com wrote: Hi, Is Pharo working Ok on the new OS X Lion? I am asking because I am considering to upgrade. Cheers, Doru -- www.tudorgirba.com Not knowing how to do something is not an argument for how it cannot be done. -- Lukas Renggli www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Popularity of Smalltalk in Software Industry
On 5 maj 2011, at 10:07, Sven Van Caekenberghe s...@beta9.be wrote: On 05 May 2011, at 09:58, Toon Verwaest wrote: Hi, I can tell you that independent of how the industry might perceive the language Smalltalk, learning Smalltalk will make you personally a better software engineer. And this is what the industry does want. You will look at programming from a new angle and this will give you an edge. This is also true for learning other old languages like Scheme or Lisp. As long as you stay within your Java / .NET bubble you will be one in a billion. If you learn Smalltalk, the fact you know something that other people might not makes you more special. The only negative part of learning Smalltalk while working on other types of applications is that you will eat your shoe 95% of the time hating that Java / .NET aren't more evolved and flexible :) As it seems that you are already working on a project revolving around Smalltalk, be very happy that you are getting the opportunity to learn it; you'll come out for the better. Lastly, don't care too much about popularity within industry. If you take the time to learn the systems for yourself you will probably learn to understand the differences yourself. You are currently also part of industry and obviously don't know Smalltalk well yet; how informed was your decision to not know Smalltalk? You are part of the industry making other people not choose Smalltalk based on your (non-)choice of not using Smalltalk; if they would all think this way! Sheep won't change anything :) cheers, Toon Very well written, Toon! And like you say, there is a danger: Smalltalk is the Red Pill, once you know it and get it, you will never want to go back. This is all too true! :-/ -- Cheers, Peter You have been warned. Sven
Re: [Pharo-project] Just starting out
Yes, I'm interested too. Sounds reminiscent of the ITAR days of the late 1990s. Wonder if I still have that T-shirt... -- Cheers, Peter. On 4 maj 2011, at 09:41, Toon Verwaest toon.verwa...@gmail.com wrote: On 05/04/2011 07:20 AM, Stéphane Ducasse wrote: this is because they are forced to do so because of a new law in the us about crypto. Believe they do not like that. What law is that, and why? Sounds interesting :)
Re: [Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?
It feels backwards to me too, in the same way that one plus one equals two feels more natural than two equals one plus one. -- Cheers, Peter. On 30 apr 2011, at 16:20, Mariano Martinez Peck marianop...@gmail.com wrote: Hi guys. I always code my tests something like this: testBlah | universalAnswer | universalAnswer := 30. universalAnswer := universalAnswer + 11. self assert: universalAnswer equals: 42. In this case, 42 is the expected and universalAnswer is the actual value. I feel weird writing like this: self assert: 42 equals: universalAnswer. I don't know why...but I do..the same as when doing should: [] raise: Error. In that case you put the actual first and the expected at the end... okthe problem is that assert:equals: is in fact: asserts: expected equals: actual instead of asserts: actual equals: expected So, with my test I would receive a description in the debugger that says 'Expected 41 but was 42.' which is completely the opposite. Of course, if I write my tests in the way I don't like, that is: self assert: 42 equals: universalAnswer. then i got the correct message 'Expected 42 but was 41.' I don't pretend pharo change this because I guess it is standard, and blah blah blah. But senders of #assert:equals: should both, some written as mine (so the message is incorrect for them) and some correct. In addition, I think it is a problem of the selector name. If we could make it clearer, the won't be necessary to confuse actual with expected. Cheers -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-project] [ANN] new mailinglist for tracker mails
Many thanks, Marcus! -- Cheers, Peter. On 18 apr 2011, at 08:23, Marcus Denker marcus.den...@inria.fr wrote: The mails from the google tracker now go to this list: http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker in turn, this means the traffic on the pharo-project list should be a bit more managable. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Good reference on time on unit testing?
Steven, you're making perfect sense to me, and I think almost everyone here agrees with you. Bill's problem (if I've understood him correctly) is that he needs to convince some pointy-haired-boss-type person, by directing him or her to a well-respected official statistic that proves what we all know to be true from experience. Sadly, I think it will be hard to find it :-( -- Cheers, Peter On Sun, Feb 27, 2011 at 9:04 PM, Steven Baker ste...@stevenrbaker.comwrote: I've always felt that test driving code actually results in negative time spent on testing. I spend (and everyone I know that tests well does as well) a lot less time writing code test-first than I ever would writing the same code without the tests first. Also, I spend far less time (almost none) manually testing functionality. So TDD results in net negative time difference. (Apologize if I'm incoherent, the cold and flu drugs are strong in this one.) -Steven On Sun, Feb 27, 2011 at 11:51 AM, Norbert Hartl norb...@hartl.name wrote: On 27.02.2011, at 13:58, Schwab,Wilhelm K wrote: Norbert, Excellent points - I take exception with only one: you assume that all developers test - that is sadly not true. I am involved with a group who seem to think that a handful of tests added at the last minute will somehow magically fix their problems. It seems I wasn't clear on this one. I'm trying to making a point that there is no distinction between testing - no testing but between testing - writing tests. If you take compilation you test the code for syntax and language quirks. If a developer runs the program he develops than he is testing already. Testing and running a program is the same form that point of view. He takes input parameter and expects output parameter. That is testing. The point is just that developers do it manually and that is not reproducable. So there is no real difference between manual testing all the time and written test case. Only that repeating the testing procedure is boring and therefor supposed to be done by a machine. So if developers could see that the just need to put the work they already doing into a test will ease the work without changing much. They are just changing style and save time. That's it. Talking about 100% test coverage and holistic views about what the perfect testing could be doesn't help. I have no problem arguing that testing (if done well) can/will reduce overall development time; the question is how much of that time one should expect to devote to writing and maintaining unit and acceptance tests? I understand your intention but the view is inapropriate. Coding and testing aren't two things. It is something that belongs together (if you changed coding style). So that's why it is hard to estimate a time that should be spent. To me it is more comparabale to this: We all know collections are great. Imagine someone asking you Can anyone recommend a good reference on the amount of time one should expect to spend writing code that uses collections?. What would you say? There is no answer. That doesn't mean you can't solve the problem. But you won't solving it by saying It is 38.345 % of the time. If people don't get it you have to convince and/or teach them. I had several times where I could show the developer that he is gaining time from doing it. That works. Everything else is targeted towards excel manipulators. Norbert From: pharo-project-boun...@lists.gforge.inria.fr [ pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Norbert Hartl [ norb...@hartl.name] Sent: Sunday, February 27, 2011 5:41 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Good reference on time on unit testing? Hi, On 27.02.2011, at 04:52, Schwab,Wilhelm K wrote: Hello all, Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. I find that really hard to answer. To me the problem is the question itself. I heard the ..amount of time one should expect to spend writing tests? so often in companies and I think it was always exactly this phrase. While the question is valid it gives the impression there is something that decucts time from your normal development work. So the people that are asking this question are often managing people that have read something about code quality and they want to apply _this_ to their teams. The definition over time is troublesome, too. Testing is not easy. Everything you read about testing gives you the impression that everyone knows how to test and that those developers are just too lazy. And that is not true. Most developers I met had problems to see what testing is all about. The don't see interfaces as provable promises etc. So if you
Re: [Pharo-project] Good reference on time on unit testing?
+100 Couldn't have said it better myself! -- Cheers, Peter. On 27 feb 2011, at 08:27, laurent laffont laurent.laff...@gmail.com wrote: On Sun, Feb 27, 2011 at 4:52 AM, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote: Hello all, Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. If you develop the TDD way (which I always do at work) then I would say this question is not valid. Your production code will be there because of tests. In legacy system, new and refactored code will be there because of tests. IMHO the questions how much time should I spend writing tests? or how many tests should I write ? are raised when tests are written after. And sadly tests often become a burden in this case and doesn't support the pressure of releases / last minute changes / ... (I've done it this way almost 10 years ago, not good :) In TDD the question is which stories / scenarios do we have to implement ?. It's more a Product owner / customer point of view. The best book on TDD I've read is Dave Astels TDD: a practical guide (Indeed, this one has really changed my mind on how testing should be done, and other books I've read since don't). Laurent Bill
Re: [Pharo-project] Smalltalk for engineers
Bearded +1 -- Cheers, Peter. On 5 feb 2011, at 13:02, Geoffroy Couprie geo.coup...@gmail.com wrote: Hello, Thanks for advertising my post :) On Sat, Feb 5, 2011 at 8:10 AM, Geert Claes geert.wl.cl...@gmail.com wrote: James Robertson spotted this post: http://unhandledexpression.com/2011/02/04/smalltalk-for-engineers/ I was especially interested in the statement you don’t understand what you can/should do ... Well, we could make a poll to see who is bearded here... Working with Smalltalk and Pharo has been a fun journey, and I'm still enjoying the ride. I especially thank Steph for introducing me to this wonderful platform!
Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken
+100 :-D -- Cheers, Peter On Sat, Jan 8, 2011 at 3:22 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: What we will do is deprecate copyFrom: from Object - copyStateFrom: add copyFrom: in Sequenceable as self copyFrom: a to: self size Stef
Re: [Pharo-project] An intuitive (or screwed) #copyFrom:
Hehehe. While I was considering whether or not to chip in on this thread, two thoughts passed through my mind. The first was that this is one of those annoying silent failures that Wilhelm would surely pick up on (so I didn't need to bring it up). The second was that #copyFrom: really should be called #copyStateFrom: to more accurately reflect what it does, and should be used for. So now this reply is completely redundant, since Wilhelm also suggested the same thing, or maybe I should just stop here and write +1 instead :-p -- Cheers, Peter On Sat, Jan 1, 2011 at 7:39 PM, Schwab,Wilhelm K bsch...@anest.ufl.eduwrote: Wow. In fairness, Dolphin has one or two such oddities. IIRC, the confusion there is that external arrays (DOUBLE, DWORD, etc.) respond to #copyFrom:to: in terms of bytes, not elements. The problem in this case appears to be that 'a string with some stuff in it' copyFrom:5 should blow up because 5 is not a suitable source (a string of some type) from which to copy a string's state. Once it properly reports abuse, we can then move on to asking whether we want a copying selector that can be so easily confused with copying from an index. It might be better named #copyStateFrom:?? Sorry to beat the usual drum, but it fits: silent failures need to be hunted down and killed. Bill From: pharo-project-boun...@lists.gforge.inria.fr [ pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Saturday, January 01, 2011 1:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] An intuitive (or screwed) #copyFrom: HI sebastian If I remember correctly you are not the only one bitten by it :) so we should do something ObjectcopyFrom: anotherObject Copy to myself all instance variables I have in common with anotherObject. This is dangerous because it ignores an object's control over its own inst vars. Now you enumeration is too complex for me :) I ask because, if so, situation goes like this: A. we think again and decide to do the right thing or we go with the alternative which is B. we leave it as invalid, as it is right now, and 1. we mislead even to smalltalkers not familiarized to squeak/pharo 2. we rationalize some clever way to see it as a feature even if it will mislead everybody (even ourselves in a hurry) 3. we lay a foundation to lightly use protocol that is typically used in collections (to do dangerous things like instVar manipulation) 4. we break encapsulation and manipulate extremely primitive things in a common sounding selector. 5. we work harder on trying to give the impression that we're leaving it like that because we're smarter than the confused people that tried to use it (proving to them that we're dumb) 6. we get involved in an unnecessarily complicated way of thinking that will complicate unnecessarily our future (guaranteed) 7. we learn how to maintain a screwed attitude in front of people trying to use intuition when using pharo 8. we stay comfortable (on the wrong foundation and for the wrong reasons) That would leave us with this question in the table: what is compatible with the Pharo's mission? is it A or B? My state of mind is always to make the world better :) Now - did you check the senders to copyFrom:? sounds ok not so many so we could deprecated it easily - did you check in other Smalltalk if this method is used or not? VW not in Object but in probe something - did you check the ansi standard? I guess that this is not there. The finder says: 'if this isn''t broken' . 15 . 'broken' no single method, strange but indeed 'if this isn''t broken' . 15 . 20 . 'broken' find copyFrom:to: Now what would be a better name copyFromObject: then on StringcopyFrom: ? Even if I would prefer (but it sucks) StringcopyFromIndex: but this is more coherent with copyFrom: index to: another Stef
Re: [Pharo-project] Dynamic Arrays view index at execution
As Henrik pointed out, foo at 1 won't even compile, let alone return
anything, because 1 isn't a valid name for a method, and at (without the
:) doesn't take any arguments.
To get the first object in an indexable collection, be it String, Array or
whatever, you use foo at: 1. To get the third object, you use foo at: 3. It
really is as simple as that.
I usually say that with Smalltalk, if what you're doing feels complicated or
hard, then you're doing it wrong. Here, you were simply missing the :.
--
Cheers,
Peter.
On 16 dec 2010, at 23:22, flebber flebber.c...@gmail.com wrote:
Henrik Sperre Johansen wrote:
Den 16.12.2010 14:48, skrev flebber:
HI
doing the pharo tutorial and I wanted to know how pharo viewed the
dynamic
array at index 3(seems smalltalk starts at 1 not 0)
From the xample simple enough
{ (2+3) . (6*6) . 'hello', ' Stef'} size. 3
from the strings example we found index by
'ProfStef' at: 1. $P
so I thought { (2+3) . (6*6) . 'hello', ' Stef'} at 3. would let me know
what the array was evaluated to after execution but it doesn't. Is it
confused because it doesn't know whether I want the third array element
or
the third character?
Led me to wonder the correct way if doing this, so that I could evaluate
array 1 * 2.
{ (2+3) . (6*6) . 'hello', ' Stef'} at 1 * at 2. 180
Cheers
What do you mean?
The dynamic array is created with three elements,
5 (2+3) at index 1,
36 (6*6) at index 2, and
'hello Stef' ('hello', ' Stef') at index 3.
at: 3 thus returns the string.
at 3 is invalid, as it is basically 2 method calls, array does not
understand a message called #at, and #3 is an invalid selector anyways.
For your second expression, writing
({ (2+3) . (6*6) . 'hello', ' Stef'} at: 1) * (at: 2) would not work,
as you're missing the receiver for the second at: call.
you'd need to do something like:
array := { (2+3) . (6*6) . 'hello', ' Stef'}.
(array at: 1) * (array at: 2). 180
Cheers,
Henry
Yes so simply if at 1 returns the first element of a string, what returns
the third element of dynamic array, do you have to assign a varaible for the
array to be able to retrieve elements?
--
View this message in context:
http://forum.world.st/Dynamic-Arrays-view-index-at-execution-tp3090891p3091774.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] good news of the year
Yay! Congrats to Igor, and Pharo! :-) -- Cheers, Peter On Sun, Dec 12, 2010 at 2:18 AM, Tudor Girba tudor.gi...@gmail.com wrote: +1 Doru On 11 Dec 2010, at 20:34, Sean P. DeNigris wrote: Very exciting! Good luck congrats, Igor. I can't wait to bask in all the improvements :) Sean -- View this message in context: http://forum.world.st/good-news-of-the-year-tp3083142p3083625.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- www.tudorgirba.com From an abstract enough point of view, any two things are similar.
Re: [Pharo-project] [ANN] 1.2 Dev Packages are loading :)
Hehehe, I sure recognize that pattern, since I've done it myself on occasion: copy/paste error when writing accessors. You write the getter first, save it, then edit it to create the setter... -- Cheers, Peter. On 9 dec 2010, at 07:35, Stéphane Ducasse stephane.duca...@inria.fr wrote: I do not understand why model: aModel ^model such kind of methods are the solution. To me it looks like a hack or a design problem On Dec 9, 2010, at 2:58 AM, Guillermo Polito wrote: Sorry, It'll fail until Issue 3385 in pharo: TextEditor doest not understand #model gets fixed. :S Cheers, Guille On Wed, Dec 8, 2010 at 8:48 AM, Marcus Denker marcus.den...@inria.fr wrote: On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote: On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote: Ok, I've done some fixes to OB and OC, and committed them to PharoTaskForces as a temporary solution. To load current configuration: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. (ConfigurationOfPharo project version: '1.2-beta2') load. Can Hudson help us in building Dev images? Yes, will set up a build for 1.2 today. I have set one up that takes 1.2 core, runs updates and then tries to build dev https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ It is failing right now. https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Popularity or not of smalltalk?
+10^27 (That's hellaplus ;-)) Best and most positive rant I've heard in a long time! -- Cheers, Peter On Wed, Dec 8, 2010 at 2:26 AM, Eliot Miranda eliot.mira...@gmail.comwrote: Hear hear!! (specific responses below) On Tue, Dec 7, 2010 at 5:21 PM, Jimmie Houchin jlhouc...@gmail.comwrote: On 12/7/2010 5:38 PM, csra...@bol.com.br wrote: Sean, Hope that additional to the fun, we can converge to an understanding how can we increase Smalltalk popularity. OTOH, I made the reference as a sample, I did not intend to have this as all encompassing list of issues nor start a thread about comparisons with other languages. As I said earlier, what is 'trivial' or 'intuitive' for some is 'maverick' or 'bizarre' for others, it is in the eyes of the beholder... ;-) My main message is more around this: although Smalltalk was a very advanced technology when its inception, present status have almost all of its characteristics embedded in present technology. Even, when newer concepts as xUnit have started in Smalltalk, the _concept_ was absorbed in mainstream technologies so again we're stuck with small delta between what Smalltalk does 'better' than the incumbent technologies we would like to replace. I can't help but disagree with this most strenuously. Almost nothing has touched Smalltalk's advanced technology. They don't have the world view or paradigm for doing so. They are languages that operate in dead cycles. They have dead processes and do dead post mortem debugging. Yuck! (yes, I know that was redundant. :) I am not a computer scientist or trained programmer. I am a creative guy who is a businessman. I find Smalltalk empowering. I also use Python when necessary, but Squeak/Pharo is my preferred language. I find myself infinitely more productive in Smalltalk than in Python. Operating in a live environment is incredibly empowering, enabling and productive. Where else can I find this. C, C++, C#, Java, Python, Ruby, VB, nope, none... Demonstrating large scale Smalltalk projects have been canceled does not prove Smalltalk's inferiority, nor that the competition (should one choose to refer to them as such) has caught up or passed us. Especially when said project was not canceled for technical reasons but political ones and for software that was/is demonstrably inferior to the already existing Smalltalk software. But what it does prove is that Smalltalk has been and can be effectively deployed for large scale projects where someone has the courage or political will to choose something different than the status quo languages. The decisions of PHBs (Pointy Haired Bosses, Dilbert) does not invalidate anything about Smalltalk. After all their primary motivation is job security, not project success. No one ever got fired for choosing, MS, Java, IBM, Oracle, etc... The biggest weakness for Smalltalk or at least our open source version in Squeak/Pharo IMHO is its integration, cooperation or access story to certain outside systems and technologies. And I speak as an end user who cannot develop a plugin, or use Alien or FFI and program in C. In my situation for example. I have to interface to either a Windows dll or to a Java library to access financial servers. No choice. So I must choose a technology which can interface their technology. In my case, I chose to use Python to interface the Windows dll. I have written a minimal Python app which accesses the dll and thus the servers to access the data and my accounts. But the business logic I am writing in Pharo. The Python app simply provides my Pharo app the data and executes the actions directed by the Pharo app. Indeed. An immature FFI, lack of dll options etc. Integration is indeed one of the biggest weaknesses. But we're making progress here. So things may be different in months, if not years. I would that I could have interfaced the dll (or Java library) directly from Pharo. But despite that obstacle I am choosing to write my app in Pharo. Most in this business are using VB/C#/Java. They do not provide the flexibility or productivity that I have in Pharo/Smalltalk. They do not enable the small guy like me as well as Pharo/Smalltalk. Yes, this is my opinion. But guess what. This is a Pharo mailing list populated by people who are for and proponents of Smalltalk. If we favored other languages and environments we would be there. Many of those on the this list are also pretty dog gone expert in the other technologies as well. They did not make their decisions out of ignorance. What I don't understand is that if you are so convinced that the advantages of Smalltalk are so minimal and of no consequence, then why are you here? I would like to see Pharo/Squeak bridge the gap to be able to interface system components or other business libraries. I would like to be able to use Pharo/Squeak anywhere I could use Python. I would like to see that there are fewer and fewer technical
Re: [Pharo-project] Teleplace is hiring...
Great news to hear that there *are* Smalltalk jobs out there after all! :-) But, still none in Sweden (yet) :-( Good luck finding the right person (or persons)! -- Cheers, Peter On Mon, Dec 6, 2010 at 11:51 PM, Eliot Miranda eliot.mira...@gmail.comwrote: Hi All, Are you eager to work on cutting-edge business communications technology? Are you passionate about UI design? Do you have significant experience implementing innovative user interfaces in Smalltalk? Do you and your peers consider yourself a strong Smalltalk programmer? If so, Teleplace is hiring and looking for someone just like you. Please send resumes to Stephen Ceplenski st...@teleplace.com, Andreas Raab andreas.r...@teleplace.com or myself, Eliot Miranda el...@teleplace.com. best Eliot
Re: [Pharo-project] Issue 3270 in pharo: fix xor: to work with blocks and booleans
+1 -- Cheers, Peter On Mon, Nov 29, 2010 at 10:49 AM, Peter van Rooijen pe...@vanrooijen.comwrote: Hi, I don't get why it should work with blocks, since evaluation of the exclusive OR operation cannot be short-circuited. Therefore there is no reason to ever use a block as an argument. #and: and #or: take a block as an argument precisely because for 50% of the receivers (i.e., false and true, respectively) it is known in advance that the value of the expression in the argument block is irrelevant, so it would be at least wasteful to evaluate it. But this reasoning does not apply to #xor:. I think it is simply a user mistake when a block is provided as argument, where a boolean is required. It's an understandable mistake (that I've made myself ;) since xor: has such similarities to or: that you automatically want to start a block unless you're really thinking about what you're doing. So, I don't see the bug. Thus, I don't see the fix. I do see obscure code (aBoolean value)and wasted time because of the extra message send. Apologies if this is a late response, I unly just saw the issue mentioned. Cheers, Peter On Thu, 18 Nov 2010 18:55:41 +0100, ph...@googlecode.com wrote: Status: Fixed Owner: marcus.denker Labels: Milestone-1.2 New issue 3270 by marcus.denker: fix xor: to work with blocks and booleans http://code.google.com/p/pharo/issues/detail?id=3270 ... so that it works like or: (calling #value on the argument. This means it will continue to work with booleans, too). Attachments: XOr.1.cs 903 bytes
Re: [Pharo-project] permutations / combinations implementation
Hi Doru! I did a lot of work with permutations and combinations a few years back when I was writing code to help me solve the challenges in Simon Singh's The Code Book. It probably isn't comprehensive (and it's all in VisualAge Smalltalk), but I expect it might provide a large chunk of what you're looking for. I could try and find it for you, if you like. -- Cheers, Peter. On 15 nov 2010, at 10:55, Tudor Girba tudor.gi...@gmail.com wrote: Hi, Is there an implementation of permutations and combinations of a collection? Cheers, Doru -- www.tudorgirba.com Presenting is storytelling.
Re: [Pharo-project] [Idiom] 'myfile.txt' asFileName readStream contents
The result you got is what I would have expected too. -- Cheers, Peter On Sat, Oct 30, 2010 at 12:50 PM, Hannes Hirzel hannes.hir...@gmail.comwrote: Hello Randal Schwartz writes in his blog http://methodsandmessages.posterous.com/writestreams-of-consciousness-going-to-xtream about streams citing Derek Williams http://derekwilliams.us/?p=1411 He gives the following as an example of elegant syntax of Smalltalk 'myfile.txt' asFileName readStream contents This does not work in Squeak nor in Pharo. It produces a ReadStream on the contents of the _String_ 'myfile.txt'. i.e. the ByteString with 10 elements. Comments? Regards Hannes
Re: [Pharo-project] [Idiom] 'myfile.txt' asFileName readStream contents
Sure, but when you send #readStream to a String, then you'll always get a ReadStream on that String. Perhaps there is a similarly-named method like #asReadFileStream that he meant to write instead (and that is just a guess, since I have no way of checking at the moment) -- Cheers, Peter On Sat, Oct 30, 2010 at 1:14 PM, Hannes Hirzel hannes.hir...@gmail.comwrote: Surely, but not what Randal implies in terms of streams I suppose The idiom implies that a file stream is created and that I get the content of a file -- not the content of the file name. --Hannes On 10/30/10, Peter Hugosson-Miller oldmanl...@gmail.com wrote: The result you got is what I would have expected too. -- Cheers, Peter On Sat, Oct 30, 2010 at 12:50 PM, Hannes Hirzel hannes.hir...@gmail.comwrote: Hello Randal Schwartz writes in his blog http://methodsandmessages.posterous.com/writestreams-of-consciousness-going-to-xtream about streams citing Derek Williams http://derekwilliams.us/?p=1411 He gives the following as an example of elegant syntax of Smalltalk 'myfile.txt' asFileName readStream contents This does not work in Squeak nor in Pharo. It produces a ReadStream on the contents of the _String_ 'myfile.txt'. i.e. the ByteString with 10 elements. Comments? Regards Hannes
Re: [Pharo-project] Compiler pedantic about ifNotNil: argument
I think this discussion has diverged a lot from the original question, which is to do with the compiler being too pedantic. #ifNotNil: and friends are the selectors of methods which just happen to give the compiler an opportunity for a nice optimization, in the case when the argument that follows is a literal block. In all other cases they can be treated as message sends. If the compiler starts to impose limitations on the language just because some magic selectors can be treated specially, then IMO it is not behaving as it should. Smalltalk is beautiful because it is so simple: everything is an object, and all processing is done by sending messages to objects. Of course, in the interests of speed, we can write a compiler that actually does something different under the covers, like causing a branch in the byte codes instead of sending a message, and of course the cases when that can be done need to be clearly defined. But that does not mean that these magic selectors should be allowed to pose limitations on how they can be used, because then we no longer have Smalltalk, we have Smalltalk-- instead. Now, the above discussion is orthogonal to the questions of what is good style, what is readable, maintainable, understandable to newbies, etc, etc. Those questions are IMO just as important, but they should have nothing do do with what the compiler is supposed to do. If the compiler is being too pedantic, then it should be fixed. Then we can start discussing good style without mixing apples and oranges together. -- Cheers, Peter On Mon, Oct 11, 2010 at 5:03 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I think that for typing in a transcript experessions when you want to experiment with something selectors are fun but not in method body. But I know that this is not a really good argument. Just feeling. May be we get trapped in our way of thinking. I personally don't like the ifTrue:ifFalse: related changes, though it's a logical change. I probably won't use that feature though. But I like the monadic block - keyword selector substitution. Maybe the best is to add a setting/preference to the compiler. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Cecinestpasunepomme best squeaksource package name!
LOL! Nice with a little Magritte humour ;-) On Mon, Sep 13, 2010 at 11:18 AM, stephane ducasse stephane.duca...@free.fr wrote: Hi Cecinestpasunepomme best squeaksource package name! Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't file in *.st exports
Better :-) The attached image is of a stack trace that shows where the error occurs, which is certainly helpful! During the execution of ArrayedCollection#mergeSortFrom:to:by:, the message #clone is sent to an instance of Array, and the message is not understood, which means that there is no method called #clone in the Array class or any of its superclasses. So the question is, why is the message being sent, when no corresponding method exists on the receiver? One possibility is that there is an error in the method where the #clone message is being sent, or that the missing method just hasn't been filed in yet. The next step would probably be to look at the file being filed in, and see what methods it contains. Perhaps it depends on another file that needs to be filed in first? -- Cheers, Peter 2010/8/19 Robert Sirois watchl...@hotmail.com No problem, Pharo's driving me crazy today hehe. It says: *** system error handling failed *** (see attached image). Thanks, RS From: oldmanl...@gmail.com Date: Thu, 19 Aug 2010 17:33:03 +0200 To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Can't file in *.st exports Pardon me for being blunt, Robert, but we're going to need a bit more to go on than some sort of weird system error. Could you please attach a file that you tried to file in, and maybe a screenshot of the error? It would certainly increase your chances of getting some help ;-) -- Cheers, Peter. On 19 aug 2010, at 17:11, Robert Sirois watchl...@hotmail.com wrote: There's some sort of weird system error when I try to fileIn a *.st file (like a class method). It asks me to CR for a debugger or any key to restart. I ended up having to force quit. This is in the latest 1.1 one-click. Thanks, RS ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] little pictures of you :)
Looks simple enough :-) http://gravatar.com/oldmanlink Cheers, Peter On Thu, Aug 12, 2010 at 4:32 AM, Serge Stinckwich serge.stinckw...@gmail.com wrote: 2010/8/11 Miguel Enrique Cobá Martínez miguel.c...@gmail.com: El mié, 11-08-2010 a las 14:09 +0200, laurent laffont escribió: +1 to pictures in website. +1 to pictures in website -1 to facebook or external sites, but... maybe gravatar.com could be used +1 http://fr.gravatar.com/sergestinckwich -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] little pictures of you :)
Indeed: http://www.facebook.com/group.php?gid=103975957018 Only 26 members at the moment, surely we can do better ;-) -- Cheers, Peter On Wed, Aug 11, 2010 at 1:27 PM, Adrian Lienhard a...@netstyle.ch wrote: Wouldn't Facebook do exactly this? Adrian On Aug 11, 2010, at 12:47 , Stéphane Ducasse wrote: Hi guys the pharo web site does not support that yet :) but I would love to have some pictures of you because this is not that fun to talk daily with people when we do not even know their faces so we could start to build a pharo fun community. Let me know what you think. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] little pictures of you :)
Hehe, I just added you ;-) On Wed, Aug 11, 2010 at 11:37 PM, Germán Arduino gardu...@gmail.com wrote: I'm the opposite, I use Facebook and all my data is there. Pics, sites, twitter, etc. Cheers. Germán. 2010/8/11 Geert Claes geert.wl.cl...@gmail.com: Norbert Hartl wrote: I just left facebook and I'm not willing to get into this again. +1 I tried but closed my Facebook account too. ps. you can add a picture on your account on the forum.world.st Nabble forums, but ideally these profile photo should probably go in the member profiles of the next/improved Squeak/Pharo Source -- View this message in context: http://forum.world.st/little-pictures-of-you-tp2321021p2321896.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Where is everyone? Watching the world cup?
Same here, nothing since Wednesday, so I assumed it was the football :-p Still now it's working again for me, so whatever the real problem was, it appears to have been fixed. -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] issue 2512 - PNG Tests failure
Hmmm, weren't these the tests that failed in 1.0 if you ran all the tests in one go? I know they were in the neighbourhood anyway, since I spent some time trying to chase them down, and recognise those method names from then. Maybe Torsten knows a bit more about them, since he was the one that put me on the trail... -- Cheers, Peter 2010/6/5 Fabrizio Perin fabrizio.pe...@gmail.com http://code.google.com/p/pharo/issues/detail?id=2512 the following tests fail: PNGReadWriterTesttestPngEncodingColors32 PNGReadWriterTesttestPngDecodingColors32 They were both green in Pharo 1.0. Also the current implementation of PNGReadWriterTest class has been file in into the last Squeak trunk image and they are green. So the last modifications on the the PNG package cause those methods fail. Cheers, Fabrizio ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?
Thanks, Lucas! I like nice clear concise lists of logical reasons like this :-) Not that I disagree with Stef in any way at all, but can you think of reasons - other than the historical ones - why #value:value:value: and friends are to be preferred over #valueWithArguments: ? -- Cheers, Peter On Wed, May 26, 2010 at 1:20 PM, Lukas Renggli reng...@gmail.com wrote: not right to me. I wanted to express the feeling that, for me, the one of the best things about Smalltalk is its readability in difference to C, which is very fast. The »new compiler optimize« both, anyway. - The New Compiler does not yet work. - The optimized #and:and:and: code never decompiled correctly. - The exact semantics of #and:and:and: is not clear without knowing how it is implemented. - There are subtle semantic differences between a and: [ b ] and: [ c ] and: [ d ] and a and: [ b and: [ c and: [ d ] ] ] if the conditions have side-effects. - The #and:and:and: constructs are very confusing to newbies, I have seen that numerous times. - The use of #and:and:and: doesn't shorten code. - #and:and:and: is not necessary from a language point of view. - And most important for me: #and:and:and: is incompatible with the rest of the world. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] how to simply double a ' inside string
Oscar, you should think of the question as: what is the simplest piece of
code that could take your string ('', which has two quotes in it) and
return a new one with four quotes in it instead of two?
--
Cheers,
Peter
On Tue, May 4, 2010 at 10:33 AM, Oscar Nierstrasz os...@iam.unibe.chwrote:
s := ''.
s size - 2
works fine for me. am i missing something?
- on
On May 3, 2010, at 22:54 , Schwab,Wilhelm K wrote:
Stef,
First, try #printString - it might do the job for you. Failing that, you
can do something like
| out |
out := WriteStream on:String new.
self do:[ :c |
c = $' ifTrue:[ out nextPut:$' ].
out nextPut:c.
].
^out contents.
I'll be interested to see all of the better ways to do this.
Bill
-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr [mailto:
pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse
Sent: Monday, May 03, 2010 3:48 PM
To: Pharo Development
Subject: [Pharo-project] how to simply double a ' inside string
Does anybody know how to double a ' inside a string?
Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] how to simply double a ' inside string
Nice! :-D Follows the KISS principle perfectly!
--
Cheers,
Peter
On Tue, May 4, 2010 at 12:08 PM, Oscar Nierstrasz os...@iam.unibe.chwrote:
Ah! Now, I get it.
What about this?
'' join: ( split: 'don''t') - 'dont'
Not as efficient as using a stream, but pretty simple.
- on
On May 4, 2010, at 10:54 , Peter Hugosson-Miller wrote:
Oscar, you should think of the question as: what is the simplest piece
of code that could take your string ('', which has two quotes in it) and
return a new one with four quotes in it instead of two?
--
Cheers,
Peter
On Tue, May 4, 2010 at 10:33 AM, Oscar Nierstrasz os...@iam.unibe.ch
wrote:
s := ''.
s size - 2
works fine for me. am i missing something?
- on
On May 3, 2010, at 22:54 , Schwab,Wilhelm K wrote:
Stef,
First, try #printString - it might do the job for you. Failing that,
you can do something like
| out |
out := WriteStream on:String new.
self do:[ :c |
c = $' ifTrue:[ out nextPut:$' ].
out nextPut:c.
].
^out contents.
I'll be interested to see all of the better ways to do this.
Bill
-Original Message-
From: pharo-project-boun...@lists.gforge.inria.fr [mailto:
pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse
Sent: Monday, May 03, 2010 3:48 PM
To: Pharo Development
Subject: [Pharo-project] how to simply double a ' inside string
Does anybody know how to double a ' inside a string?
Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what expectedfailures expected to do?
I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com Live like you mean it. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what expectedfailures expected to do?
Thanks for answering, Doru! So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting work in progress, and not for production code? -- Cheers, Peter On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected failures my bar was green. So expected failures really expect that the tests failed? We cannto have green tests in there? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what expectedfailures expected to do?
On Wed, Apr 21, 2010 at 11:34 AM, Tudor Girba tudor.gi...@gmail.com wrote: Basically yes. It's not just for giving it to someone else, but also for yourself. The idea is to quickly notice when tests change color (from green to red), so instead of remembering how many failed before and comparing with the current number of failures, you simply mark them as expected failures and your bar becomes green. Thanks, I think I get it now. So really, I shouldn't expect to see any expected failures in Pharo 1.0, but since Pharo 1.1 is still in alpha, it would be OK to have some there until it's ready for release. -- Cheers, Peter Doru On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: Thanks for answering, Doru! So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting work in progress, and not for production code? -- Cheers, Peter On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM, Adrian Lienhard wrote: Yes, if a test that is expected to fail does not fail, this is treated as a failure. I think that makes sense. well it depends about the scenario. you put on expectedfailures something that gets in your way now, so after if it works even better. of course you should get notified that the test is green while expected it to failed. Now it leads to a UI problem where you have a failure that passes so when you click on it nothing happens: no debugger. And you can wonder why the hell do I have a failure when my tests pass. So I think that this implementation of expectedFailures is a hack. Adrian On Apr 20, 2010, at 21:57 , Stéphane Ducasse wrote: Hi I tagged some tests as expected failures and I got a strange behavior. On the the tests which was passing was listed under the failures. When I renamed the method without updating the expected
Re: [Pharo-project] what expectedfailures expected to do?
On Wed, Apr 21, 2010 at 1:37 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Apr 21, 2010, at 11:47 AM, Peter Hugosson-Miller wrote: On Wed, Apr 21, 2010 at 11:34 AM, Tudor Girba tudor.gi...@gmail.com wrote: Basically yes. It's not just for giving it to someone else, but also for yourself. The idea is to quickly notice when tests change color (from green to red), so instead of remembering how many failed before and comparing with the current number of failures, you simply mark them as expected failures and your bar becomes green. Thanks, I think I get it now. So really, I shouldn't expect to see any expected failures in Pharo 1.0, but since Pharo 1.1 is still in alpha, it would be OK to have some there until it's ready for release. in a perfect world now in pharo we have tests that are red and we could not fixed easily. Ah, OK. I guess it's really a question of perception. The world in which I work is a bit different from the wonderful world of Pharo (no sarcasm intended!), in that we can't ship *anything* unless *all* our tests are green. The concept of expected failures just has no place, because as long as there are failures we still have work to do. I can understand Doru's description of an expected failure as a kind of bookmark, to be added and discarded during the day, but I get a bit nervous that the sight of too much green might make me miss the fact that I'm not finished yet :-p -- Cheers, Peter Doru On 21 Apr 2010, at 11:28, Peter Hugosson-Miller wrote: Thanks for answering, Doru! So if I've understood you correctly, expected failures are useful when one wants to give some code to someone else, with all the tests running green, but at the same time let that person know that some specific tests are really still red, but known about. In other words, are they simply a way of documenting work in progress, and not for production code? -- Cheers, Peter On Wed, Apr 21, 2010 at 11:12 AM, Tudor Girba tudor.gi...@gmail.com wrote: Hi, The idea behind this is that you can use unit tests to document things you have not done yet, or bugs that you know about but you do not want to spend time working on right now. Simply reverting the assertion in your test does make the test runner green, but it fails to document the intention, and a newcomer might get to the false conclusion that the answer is not 42. By marking the test as expected failure, you make the test runner green, but you also explicitly say that the answer should be 42, but the machine is not quite perfect yet. Cheers, Doru On 21 Apr 2010, at 11:06, Peter Hugosson-Miller wrote: I'm trying to follow along with this discussion, but now I feel really stupid :-( I've been using SUnit since 1998 (when it was still called BeckTestingFramework), and ever since expected failures showed up, I've never understood them. So I wonder if some kind guru-like person could please explain to me what they are useful for? I mean, to my way of thinking, if one writes a test that is expected to fail, then why not invert the test and call it a success instead? for example: self should: [answer = 42] ...as an expected failure could simply be re-written as self should: [answer ~= 42] ...right? No, obviously I've missed something really obvious and important, and that's why I'm asking the question now. Please be gentle ;-) -- Cheers, Peter On Wed, Apr 21, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: We should have a look at what adrian did now the problem is that understanding a large set of changes is more difficult than a couple of simple ones. If somebody want to help we are open. Stef I think Adrian Kuhn did that in his SUnit work. I also remember he also introduced a difference between expectedFailures and expectedErrors. Doru On 21 Apr 2010, at 10:16, Stéphane Ducasse wrote: On Apr 21, 2010, at 9:51 AM, Adrian Lienhard wrote: Yea, I agree, the GUI is suboptimal. I still think, though, that treating this case as a failure is correct. For instance, consider the case where you had added a workaround to a known bug and when the bug is fixed you need to remove the workaround again. Maybe it even leads to a wrong behavior now that the bug is gone. In this case you really want to know that the test does not fail anymore. yes Now I have the impression that expectedFailures should be like passes, failed, errors: a state of the tests. Stef In any case, I think that tagging methods as expected failures should be done with pragmas and not with #expectedFailures. Like this it would also be much easier to understand what's going on when you have a failure in this test although all assertions pass. Adrian On Apr 21, 2010, at 08:22 , Stéphane Ducasse wrote: On Apr 20, 2010, at 11:20 PM
[Pharo-project] Hints and clues for a Pharo newb
Hi all, So it's time for me to stop lurking and do some stuff. However, although I am an experienced Smalltalk programmer (VisualAge Smalltalk continuously since 1995), I am a complete newb when it comes to Pharo and Squeak, it's hard to find my way around, and it's going to take me some time to get up to speed. I'm working on a small improvement to the testing framework, using ideas that I have found to be very useful in my daily job over the past 15 years. Note that I am doing this from scratch, so that I don't accidentally steal anything that I've done in my work, but I know how it all works in VisualAge, so I feel sure that I'll eventually be able to find the corresponding classes and methods in Pharo. What I would like are a few hints, clues and nudges in the right direction for scenarios and questions that I will describe in this thread. What I *don't* want are full-blown solutions, because then I won't learn anything. I hope that some kind souls will be able to give me a little help in the beginning that will eventually bring me up to speed and let me be productive. So to start with, one scenario and one question: 1) I want to find or write a method on Process that will print a stack trace onto a supplied Stream. Ideally I'd like to be able to decide the start and stop depth of the trace, so for example if I know that the top 4 stack frames will always be uninteresting, I would want to be able to write something like this: Processor activeProcess printStackFrom: 5 to: 15 on: aStream. 2) What *exactly* is thisContext? It appears to be a reserved word in Pharo, just like the familiar self, super, true, false, nil that are always reserved in Smalltalk. I'd also like to get an idea of what it's good for, and if anyone can describe it in terms of something that is in VisualAge, that would be nice too :-) BTW, if this is not the appropriate place for a thread like this, then please tell me where I should put it (politely, of course :-p) -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
Stef, I like how you're thinking, but your list raises one question in my mind: how do you propose to load anything into Mini without a Compiler? Sorry if that's a stupid question, but I need to know :-p -- Cheers, Peter. On 20 apr 2010, at 08.59, Stéphane Ducasse stephane.duca...@inria.fr wrote: The question is what we call core. I think that core should contain less and less but pharo should contain infrastructure and FFI or Alien are infrastructure. If you look at my answer to German on Re: [Pharo-project] Really Important message (tm) April 16 You can see that with a fast loading package mechanism then we could really introduce in Pharo-Core (= what we have now) infrastructure package to produce Pharo and works on making a real core. FFI does not belong to this core=mini but to Pharo from my point of view Mini Mini + FFI + Tools + IDE + Compiler = PharoCore Pharo + Sounds + Morphic examples + archiview = Pharo Note that the belonging of one package to group is not automatically clear. This is why metacello is key and a metacelloRepository. Steg I wouldn't include neither FFI or Alien FFI in neither PharoCore or PharoDev image. +1 That's only my opinion. Maybe Stef should tell us more about why he thinks it should be included. Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FFI in 1.1
On 20 apr 2010, at 09.13, Stéphane Ducasse stephane.duca...@inria.fr wrote: On Apr 20, 2010, at 9:06 AM, Peter Hugosson-Miller wrote: Stef, I like how you're thinking, but your list raises one question in my mind: how do you propose to load anything into Mini without a Compiler? Sorry if that's a stupid question, but I need to know :-p In my coolest dream: socket + object serializer like in some versions of S# of dan simmons. Aha! Très très cool! :-D Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Inserting halts using pragmas?
On Mon, Apr 12, 2010 at 11:11 AM, Lukas Renggli reng...@gmail.com wrote: Hi, can we inserts halt's into methods without modifying source code, using pragmas maybe? This has nothing to do with pragmas. Pragmas do not change execution behavior of a compiled method. Also pragmas are in the source code, so you cannot add them without changing the source. There was some work on annotations by Marcus, this goes more into the direction you are looking for. What I would do is to replace a compiled method with a custom object that implements #run:with:in: and that opens a debugger at the right place. Yes, that's more or less how VisualAge does it. See DbgBreakpointedMethod, a variable Subclass of CompiledMethod. -- Cheers, Peter Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko siguc...@gmail.com wrote: Oh.. again.. @Ralph: if you don't want sets with nils, just don't put them there. Why this isn't obvious for you? Take a Squeak , which already supporting nils in sets. Have you seen ANY reported breakage of existing code because of this? On 12 April 2010 05:25, Levente Uzonyi le...@elte.hu wrote: On Sun, 11 Apr 2010, Ralph Boland wrote: Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? Stef I think moving Dictionary out from under Set is a great idea. However I am not convinced having a class HashedCollection to share common code between Set and Dictionary is worth it. I would just tolerate the code duplication because these classes are so important. Given that Squeak is going to support I don't see your point here. In Squeak that would mean duplicating 17 + 9 methods (instance/class side) + the two instance variables for no reason. HashedCollection though, I would hate to see yet another difference between Pharo and Squeak. I expect that the difference is unlikely to break code shared between Pharo and Squeak though. I was always against allowing the addition of nil to sets. This change means that every time I accidentally add nil to a set the error will go undetected and will be difficult to track down once the problem is discovered. Collections are still not ment to be bug detectors... Btw, do you notice if you add nil as a key to a Dictionary? (or add nil to an OrderedCollection?) My solution to escape this change in my code will be to subclass Set and any of its subclasses that I use and add code in the subclasses to test for addition of nil and report an error when it happens. This will allow bugs to show up sooner. You can (ab)use PluggableSet if you really need this by adding the nil check to the hashBlock. An alternative is just to modify Set itself by adding a test for adding nil to a set and then reporting an error. This change will break down of course once there are instances of actually adding nil to a set in Squeak/Pharo. Are there any such occurrences is Squeak 4.1? Who knows, nil can be everywhere: #(1 2 nil) asSet. Now that this feature will be in Squeak 4.1, however, we again have the problem of divergence of code between Pharo and Squeak. The problem won't be there immediately but eventually this feature will actually be used in Squeak. Of course the issue here is how often it is useful to allow addition of nil to a Set. For the approximately 100,000 lines of code I have written in Smalltalk the answer is 0 explaining my opposition to this change. For some others though the answer must be different. For me this change will delay my moving my code from Squeak 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). Note that I use Sets and Dictionaries a lot. When my Squeak project runs 80% of the time is spent on Set/Dictionary operations. You could have added nil as a key to a Dictionary and that went undetected... Levente Regards, Ralph Boland ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Heh, well I understand Ralph's point quite well, since I know that in the project I'm working on there are places in the code that depend on the fact that sets can't contain nil. So the following would break if VisualAge added that possibility: #( 1 2 3 4 nil 6 7 nil) asSet asArray = #(1 2 3 4 6 7) I'm not deciding one way or the other which way is right, just adding an observation. -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Mon, Apr 12, 2010 at 2:06 PM, Igor Stasenko siguc...@gmail.com wrote: 2010/4/12 Peter Hugosson-Miller oldmanl...@gmail.com: On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko siguc...@gmail.com wrote: Oh.. again.. @Ralph: if you don't want sets with nils, just don't put them there. Why this isn't obvious for you? Take a Squeak , which already supporting nils in sets. Have you seen ANY reported breakage of existing code because of this? On 12 April 2010 05:25, Levente Uzonyi le...@elte.hu wrote: On Sun, 11 Apr 2010, Ralph Boland wrote: Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? Stef I think moving Dictionary out from under Set is a great idea. However I am not convinced having a class HashedCollection to share common code between Set and Dictionary is worth it. I would just tolerate the code duplication because these classes are so important. Given that Squeak is going to support I don't see your point here. In Squeak that would mean duplicating 17 + 9 methods (instance/class side) + the two instance variables for no reason. HashedCollection though, I would hate to see yet another difference between Pharo and Squeak. I expect that the difference is unlikely to break code shared between Pharo and Squeak though. I was always against allowing the addition of nil to sets. This change means that every time I accidentally add nil to a set the error will go undetected and will be difficult to track down once the problem is discovered. Collections are still not ment to be bug detectors... Btw, do you notice if you add nil as a key to a Dictionary? (or add nil to an OrderedCollection?) My solution to escape this change in my code will be to subclass Set and any of its subclasses that I use and add code in the subclasses to test for addition of nil and report an error when it happens. This will allow bugs to show up sooner. You can (ab)use PluggableSet if you really need this by adding the nil check to the hashBlock. An alternative is just to modify Set itself by adding a test for adding nil to a set and then reporting an error. This change will break down of course once there are instances of actually adding nil to a set in Squeak/Pharo. Are there any such occurrences is Squeak 4.1? Who knows, nil can be everywhere: #(1 2 nil) asSet. Now that this feature will be in Squeak 4.1, however, we again have the problem of divergence of code between Pharo and Squeak. The problem won't be there immediately but eventually this feature will actually be used in Squeak. Of course the issue here is how often it is useful to allow addition of nil to a Set. For the approximately 100,000 lines of code I have written in Smalltalk the answer is 0 explaining my opposition to this change. For some others though the answer must be different. For me this change will delay my moving my code from Squeak 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). Note that I use Sets and Dictionaries a lot. When my Squeak project runs 80% of the time is spent on Set/Dictionary operations. You could have added nil as a key to a Dictionary and that went undetected... Levente Regards, Ralph Boland ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Heh, well I understand Ralph's point quite well, since I know that in the project I'm working on there are places in the code that depend on the fact that sets can't contain nil. So the following would break if VisualAge added that possibility: #( 1 2 3 4 nil 6 7 nil) asSet asArray #( 1 2 3 4 nil 6 7 nil) asSet in squeak before adding sets-with-nils you won't see such code , because this will throw an error. And so, nobody used it in that way before. I mean, there is no code in old squeak codebase which putting nils into sets intentionally. So, either you intentionally puting nils there - and its completely OK, or you intentionally do not putting them (as all old code does) - which is also , completely OK. = #(1 2 3 4 6 7) I'm not deciding one way or the other which way is right, just adding an observation
Re: [Pharo-project] who is maintaining shout?
I absolutely agree with Torsten. Here's one I made myself for VaSt, and I've been using it for 8 years now: [image: PehuTextEnhancer.png] Note (whatever you might think of all the other fonts and colours) that the comments are green ;-) -- Cheers, Peter On Wed, Apr 7, 2010 at 4:39 PM, Torsten Bergmann asta...@gmx.de wrote: Stef wrote Because I would like to change the default color of comments. Green is really ugly for the release. Please no! This is subject to personal taste. In most text editors and IDE's I know the comments are always green by default independent from language. So I would keep it since this is what is common in developer tools. If you want you can have your own. So shout is already what most users may expect. Please keep it. See C/C++ Eclipse http://img.brothersoft.com/screenshots/softimage/e/eclipse_ide_for_c-c++_developers-133195-1.jpeg C/C++ VStudio http://www.lisisoft.com/imglisi/4/OptimizeUtilities/51119text-editor-pro-screenshot.jpg PHP Antechius http://www.lisisoft.com/imglisi/7/HelpfileTools/37086phpedscreen.jpg JavaScript http://assets.devx.com/articlefigs/19100.png Java Eclipse http://www.oio.de/public/opensource/eclipse/eclipse_editor.jpg C# Eclipse http://emonic.sourceforge.net/html/CSharpEditorWithCompletion.jpg VB SharpDevelop http://www.borncity.de/Net/Img/SharpDevelop.jpg ... Bye T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project PehuTextEnhancer.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Having fun with booleans
On 5 mar 2010, at 09.33, Fernando olivero olive...@lu.unisi.ch wrote: The problem is the side effects, is suddenly Booleanand: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated. No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure. But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading. -- Cheers, Peter Fernando On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead. a b ifTrue: [ ... ] could be written as: a b and: [ ... ] a b ifFalse: [ ... ] could be written as: a b or: [ ... ] and a b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as: a b and: [ self foo]; or:[ self bar ] :) -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Having fun with booleans
On 5 mar 2010, at 10.17, Henrik Johansen henrik.s.johan...@veloxit.no wrote: Den 05.03.2010 10:08, skrev Peter Hugosson-Miller: On 5 mar 2010, at 09.33, Fernando olivero olive...@lu.unisi.ch wrote: The problem is the side effects, is suddenly Booleanand: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated. No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure. But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading. -- Cheers, Peter I like that argument turned on its head, namely that ifTrue: ifFalse: gives the reader a very strong hint that the argument blocks are used purely for branching, thus using them to (eventually) return a boolean can be seen as misleading :) i.e. I tend to prefer to use Igors and: example for code I often see written a b ifTrue: [... a couple of actions, then returning true or false ...] ifFalse: [^false] And I'm definitely with you on that score! In fact it's how I decide which method to use :-) -- Cheers, Peter Cheers, Henry Fernando On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote: Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead. a b ifTrue: [ ... ] could be written as: a b and: [ ... ] a b ifFalse: [ ... ] could be written as: a b or: [ ... ] and a b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as: a b and: [ self foo]; or:[ self bar ] :) -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
On Thu, Mar 4, 2010 at 10:08 AM, Lukas Renggli reng...@gmail.com wrote: Strange to see how subjective it is... My brain is well trained to rectangle blocks and I arrive to the opposite conclusions on each point. I agree 100% with all that Doru wrote. These patterns have been successfully used for almost a decade in open-source projects like Seaside, Moose, Magritte, Mondrian, Pier, Glamour, PetitParser, Grease, OmniBrowser, SqueakSource, ... Indeed, it appears to be very subjective, with clearly stated arguments for both sides, so it's doubtful there will ever be consensus on this. FWIW, I agree 100% with everything Eliot wrote (although I admit he piqued my curiosity with the mention of the trailing period :-p Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] #ensure: issues
In case anybody is interested, I tried Henrik's example in VAST:
| proc |
proc := [[Transcript show: 'Start!']
ensure:
[Transcript show: 'Finish!'.
Processor yield]]
newProcess.
proc resume.
Processor yield.
proc suspend.
proc terminate.
on my machine it prints: Start!Finish!
--
Cheers,
Peter
On Thu, Mar 4, 2010 at 1:19 PM, Stéphane Ducasse
stephane.duca...@inria.frwrote:
btw henrik
does VW have the same behavior?
Stef
On Mar 4, 2010, at 11:38 AM, Henrik Johansen wrote:
FWIW, this quote from the following discussion on Squeak-dev distills
what I was trying (but failing) to demonstrate:
We shouldn't stop trying to support well-behaved ensure blocks properly.
Because if we don't then ensure
becomes entirely random. Or can anyone here explain why it would be
reasonable to expect that this version works:
p := [[Processor yield] ensure:[Transcript show: 'finished']] fork.
Processor yield.
p terminate.
but this one doesn't:
p := [[] ensure:[Processor yield. Transcript show: 'finished']] fork.
Processor yield.
p terminate.
(we're using yield here to denote any kind of process switch) If the
only thing that determines whether an ensure block is executed is a
process switch, then we basically have random, non-predictable unwind
handling. Which is a problem that is entirely unrelated to whether the
unwind block is itself well-behaved or not.
In a book with chapters discussing topics such as ensure and processes,
(based on Pharo 1.0 which is unlikely to contain any fixes for such an
issue), it deserves at least a mention.
Cheers,
Henry
Den 03.03.2010 15:33, skrev Levente Uzonyi:
On Wed, 3 Mar 2010, Stéphane Ducasse wrote:
On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote:
On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote:
PS. For the not-so-faint-of-heart, open a Transcript and try
evaluating:
|proc|
proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show:
'Finish!' Processor yield.]] newProcess.
proc resume.
Processor yield.
proc suspend.
proc terminate.
Why don't we get it printing?
Forgot a . there, supposed to be
|proc|
proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show:
'Finish!'. Processor yield.]] newProcess.
proc resume.
Processor yield.
proc suspend.
proc terminate.
on my machine it prints:
*Start!Start!Finish!
The problem occurs because Transcript #endEntry (sent from #show:)
takes a while to execute, so the process (proc) prints 'Start!', but
it gets terminated before execution reaches #resetContents (#reset in
Squeak). So 'Start!' is still in the stream. Then our process executes
the
#ensure: block and it prints 'Start!' and 'Finish!' too.
Thanks for the explanation levente!
But I'm still dizzy :) why Transcript show: 'Finish' would also print
'start' ?
Transcript is just a stream. #show: is just a combination of
#nextPutAll: and #endEntry. #endEntry displays the contents of the stream
and when that's done it removes everything from the stream with
#resetContents. #resetContents is never executed, because the process is
terminated before that. So the contents of the stream are kept and displayed
again later.
Levente
There's worse problem with #ensure: and #terminate is that, a process
executing an #ensure: block can be terminated. If you evaluate this code:
| process stage1 stage2 stage3 counter |
stage1 := stage2 := stage3 := false.
counter := 0.
process := [
[ stage1 := true ] ensure: [
stage2 := true.
100 timesRepeat: [ counter := counter + 1 ].
stage3 := true ] ] newProcess.
process resume.
Processor yield.
process suspend.
process terminate.
1000 milliSeconds asDelay wait.
{ stage1. stage2. stage3. counter } explore
you will find that stage1 and stage2 is reached as expected, but
stage3 is not and counter is less than 100. That's because the forked
process started evaluating the #ensure: block, but it was terminated by our
process.
Is this the expected behavior when sending #terminate to a process
which is evaluating an #ensure: block?
Cheers,
Balázs Levente
*yay
Henry*
*
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Re: [Pharo-project] Having fun with booleans
Hehe, it wouldn't surprise me if some of those examples would compile to the same byte codes. Have you tried decompiling to see what you get? -- Cheers, Peter. On 5 mar 2010, at 08.22, Igor Stasenko siguc...@gmail.com wrote: Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead. a b ifTrue: [ ... ] could be written as: a b and: [ ... ] a b ifFalse: [ ... ] could be written as: a b or: [ ... ] and a b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as: a b and: [ self foo]; or:[ self bar ] :) -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about code formatting in pharo
Really? That's the first time I've ever seen a lonely left bracket like that, in all my 15 years of Smalltalk experience! So for me personally, Beck's rule 3 is the one that looks better. -- Cheers, Peter On Wed, Mar 3, 2010 at 10:19 AM, Adrian Lienhard a...@netstyle.ch wrote: I don't like Beck's rule 3. Rectangular Block: b ifTrue: [self clearCaches. self recomputeAngle] I prefer (and this is how most other people format blocks in my experience): b ifTrue: [ self clearCaches. self recomputeAngle ] Adrian On Mar 3, 2010, at 10:03 , Stéphane Ducasse wrote: On Mar 3, 2010, at 9:26 AM, Torsten Bergmann wrote: Gary wrote: The answer is that the code is formatted when viewing, from, potentially, unformatted code. Should please everyone. +1 Looks like in Squeak the rules from Ward Cunningham are now used for pretty print: http://c2.com/ppr/formatting.html#2 I love them! we should point the wiki to this page!!! See Compiler-cmm.131.mcz in Squeak. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Substrings for strings?
location := 5. length := 3. result := 'Foo Bar Baz' copyFrom: location to: position + length - 1 2010/2/20 Nathan Tuttle nathan.tut...@gmail.com I can't find any method that allows me to take a substring out of a string my location and length. Anyone know? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Substrings for strings?
On 20 feb 2010, at 02.44, Nathan Tuttle nathan.tut...@gmail.com wrote: Thank you very much! ...says he, generously ignoring my copy/paste error. Seriously, when will I learn not to post untested code in an email, no matter how trivial it seems at the time? Still, at least I spelled the method name correctly :-p. -- Cheers, Peter 2010/2/19 Peter Hugosson-Miller oldmanl...@gmail.com location := 5. length := 3. result := 'Foo Bar Baz' copyFrom: location to: position + length - 1 2010/2/20 Nathan Tuttle nathan.tut...@gmail.com I can't find any method that allows me to take a substring out of a string my location and length. Anyone know? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo changing the game
On Fri, Feb 12, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: another point, what about automatic initialize? At one point in the past VW (eliot) was really for introducing it in VW since it would not cost anything in presence of the JIT. Dolphin people did it on Model but they told me that if they could they would remove it. and this is a really important change to lower the entry level and burden of newcomers. Now because of compatibility we have to code without it for me this is a drawback. I know this is probably a stupid question, but rather than miss something important, I'll take that risk :-p What do you mean by automatic initialize? -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Pharo changing the game
On Fri, Feb 12, 2010 at 3:33 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi Peter there is no stupid question! Only people afraid to ask. Stupidity is when you ask three times the same question. In this list we can ask all the stupid question we want. So thanks for taking the risk :) automatic initialize= calling automatically initialize when calling new avoid to have to all the time write Box classnew ^ super new initialize ; yourself kind of desastrous for newbies. You know after two lectures you have to nearly explain metaclasses, and deep super + method lookup... In Squeak 3.7 we got a chance to have an agreement to have Behavior new ^ self basicNew initialize Objectinitialize ^ self and some shortcuting behavior on array to speed up the system. it makes so many things much much nicer. On Feb 12, 2010, at 3:15 PM, Peter Hugosson-Miller wrote: On Fri, Feb 12, 2010 at 10:30 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: another point, what about automatic initialize? At one point in the past VW (eliot) was really for introducing it in VW since it would not cost anything in presence of the JIT. Dolphin people did it on Model but they told me that if they could they would remove it. and this is a really important change to lower the entry level and burden of newcomers. Now because of compatibility we have to code without it for me this is a drawback. I know this is probably a stupid question, but rather than miss something important, I'll take that risk :-p What do you mean by automatic initialize? -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Thanks, Stef, Cesar So you're still talking about having the message #initialize being explicitly sent from within the #new method, right up there on Behavior. I definitely like this arrangement: one of the first things I always do is to implement #new that way, as far up as I can in the domain object hierarchy. For a moment there I imagined you meant some behind-the-scenes-magic, and that the #initialize send would not be explicit anywhere in the code. Now I can relax again ;-) -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] For those who use Nabble ....
On Wed, Jan 27, 2010 at 10:02 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: +1 We are more than a fork! Stef Absolutely! At the very least, we are a Phork! :-p -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Time for a new election in squeak.org soon
PS. I still consider Pharo and Squeak to be highly intertwined communities so input from Pharons/Pharaos/Pharooosies/p... ah, what are you guys called? :) ...is also welcome. Hmmm... Pharies maybe ;-) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Time for a new election in squeak.org soon
On 14 jan 2010, at 21.33, Igor Stasenko siguc...@gmail.com wrote: 2010/1/14 Eliot Miranda eliot.mira...@gmail.com: On Thu, Jan 14, 2010 at 12:04 PM, Martin McClure mar...@hand2mouse.com wrote: Peter Hugosson-Miller wrote: PS. I still consider Pharo and Squeak to be highly intertwined communities so input from Pharons/Pharaos/Pharooosies/p... ah, what are you guys called? :) ...is also welcome. Hmmm... Pharies maybe ;-) Pharaohs! ...now if we were still using initials instead of full names I would look for who had the initials tut... I wish we had more Cleos in the community Programming was never been popular among Cleos. I can count all of womans, who i knew seem to do some programming using only my single hand fingers ;) Yes, and it's a crying shame! Still, on Tuesday I'll be holding a course to introduce a couple of colleagues to Smalltalk, and one of them is a Sussie. I'll be sure and mention this community on my course, so fingers crossed that I can get her interested! -Martin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About moving tmp closer their use
I remember the first time I ever tried Squeak all those years ago, this was the first thing that bit me - not being able to declare temporary variables within the blocks that use them. I was so used to doing that from VisualAge. So, I vote in favour of the change :-) On Mon, Jan 4, 2010 at 1:58 PM, Igor Stasenko siguc...@gmail.com wrote: My own preference is a balance between being readable and efficient. At first, i care above anything to make my code readable. And I think that, being properly formatted, declaring temps in blocks scope not makes code less readable. Also, i think that keeping variables close to desired scope, will instead could help improving code readability. But i must say, we should learn teach developers to write code short consise, or at least attempt to (following a well known smalltalk practice - 1/2 lines per method). Then we wouldn't need to choose, what way of declaring temps is better ;) 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. From my hackish lisping state of mind I like it now what do you prefer? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Gofer git
Hmmm... Examples 6 and 7 look the same to me, care to explain further? -- Cheers, Peter. On 14 dec 2009, at 09.11, Lukas Renggli reng...@gmail.com wrote: The latest version of Gofer should be more stable. I've rewritten most internal implementation details, the tests should run faster and they do not depend on an external repository anymore. Most of the core functionality is now tested, not just things that are easy to test. I did the following changes: 1. I've renamed #addPackage: and #addVersion: to #package: and #version:. The #add: caused some confusion and people asked me what was done at this point. Since this is just a plain specification of a package or a version it is now called like that. It is also shorter. 2. Gofer doesn't support any longer to work on different repository groups in one operation. I've never used it and it made the implementation more complicated than necessary. The order in which things are defined in Gofer doesn't matter anymore. The following specification would try to operate on the packages Seaside2.8a1, Scriptaculous and RSRSS2 in the repositories of Seaside and rsrss. Gofer new squeaksource: 'Seaside'; package: 'Seaside2.8a1'; package: 'Scriptaculous'; squeaksource: 'rsrss'; package: 'RSRSS2' The above snipped is the same as the one below (which is the preferred way of writing it): Gofer new squeaksource: 'Seaside'; squeaksource: 'rsrss'; package: 'Seaside2.8a1'; package: 'Scriptaculous'; package: 'RSRSS2' 3. Gofer prefers to load versions from faster repositories. The package-cache and local file-directories have higher priority than remote repositories. 4. Gofer implicitly declares the local package cache as a repository. To disable this, send the message #disablePackageCache to the Gofer instance. 5. Gofer throws errors if a repository is not reachable. To disable this, send the message #disableRepositoryErrors to the Gofer instance. The example below will silently load the latest Seaside version from the package-cache, if the remote repository is not reachable (network error, squeaksource down, invalid repositor): Gofer new disableRepositoryErrors; squeaksource: 'Seaside'; package: 'Seaside2.8a1'; load 6. The following command fetches all versions of SomePackage into the local package-cache that are not downloaded yet: Gofer new squeaksource: 'repository'; package: 'SomePackage'; fetch 7. The following command commits all versions of SomePackage into the remote repository that are not uploaded yet: Gofer new squeaksource: 'repository'; package: 'SomePackage'; fetch 8. Gofer has better support for FTP repositories: Gofer new url: 'ftp://wtf-is-ftp.com/code'; ... 9. And local directories: Gofer new directory: '/home/renggli/repository'; ... 10. And local directories with subdirectories: Gofer new directory: '/home/renggli/repository/*'; ... With all this new functionality there might be bugs :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] linked in pharo group :)
Thanks Stef! Kind of like Facebook in a suit, isn't it? ;-) -- Cheers, Peter On Tue, Dec 8, 2009 at 2:33 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: You can register :) Not sure that this is useful but may be fun :) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] newinspector?
Rather than a mode for inspecting dictionaries, wouldn't it be better to have a subclass, say DictionaryInspector, which could be selected as needed by means of an #inspectorClass method. Then, if more specializations turn up, they could be added in the same way. Just a thought that struck me. -- Cheers, Peter. On 26 nov 2009, at 20.01, Stéphane Ducasse stephane.duca...@inria.fr wrote: Ok I will check. may be we can have a mode that does not provide object interpretation (for dict we would only see tally and array not the dictionary, ...). Stef On Nov 26, 2009, at 7:40 PM, Adrian Lienhard wrote: Just yesterday, I asked Frederic to remove the class and method entries that add a lot of the noise and are most often not needed. He committed a new version with these changes. But from Stef's analysis it seems there is a bit more needed to make this inspector fly... And a really good inspector is key! Another item to add to Stef's list: what is the point of the item Keys? I can see the keys of the dictionary already by opening Elements. So this seems superfluous. I wonder why inspecting a dictionary could not be reduced to the information that is actually of interest, namely the keys and their values. So when opening a dictionary, the subtree would directly display the keys in the left pane (no array, tally, Keys, Elements). If a key is selected, its value is printed in the right pane. Expanding a key would dive into its associated value. Actually, I think what I described here is more or less the behavior of the old explore tool. Cheers, Adrian On Nov 26, 2009, at 18:39 , Stéphane Ducasse wrote: Hi guys again I did a demo of smalltalk and the newInspecotr got in my way. I tried to analyze what did not work: - apparently the refresh does not work. Does change in instance variables get refreshed in the inspector? I try to understand what get in my way in general. - when an object has few instance variable I think that it is lost in the sea of trees. - I think that the | class is not useful at the top level. May be just having Class: and the class Name is enough no need for the | May be the Class : ByteString should appear after the Elements: - the | methods to be useful should be sorted by category in the screenshot Why do I see the instance variable of the dictionary (array and tally) I find that confusing? Because I get elements and at the same time the instance variables. I do not understand why some lines are bold and other blue When we click on connectInfo I see on the right pane - size : 5 [#host] : a SocketAddress (size: 24) [#loginMethod] : #zork [#password] : nil [#port] : 110 [#user] : 'stephane.ducasse' But I cannot modify anything. What is the point to have Elements expanded in the left pane when I get the contents by clicking on the instance variable and getting the contents on the right. Then Keys should probably close to Elements. I do not see the point to have | for individual method I do not understand why we see Elements and ByteCode I get a DNU when I click on Elements of a method BTW Screen shot 2009-11-26 at 6.14.31 PM.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About end of line convention
Exactly! +100 FWIW, this us the behaviour of Textpad, my favourite Windoze text editor. -- Cheers, Peter. On 20 nov 2009, at 01.49, Martin McClure mar...@hand2mouse.com wrote: IMO, a useful behavior for a text file editor is to: * On open, detect the line end convention of the file and remember it. This is not too hard to do as long as the file is in fact a text file (if it's a binary file you shouldn't be using a text editor on it). * On save, save in the same line end convention that the file previously had. * On save as provide the opportunity to change the line end convention as well as the file name. * New files should default to the platform's line end convention, but again be overridable on save. Regards, -Martin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?
Results for VisualAge (just FYI): | count | count := 0. [1 to: 1000 do: [:i | count :=count + 1]] timeToRun. 151702 | count | count := 0. [1000 timesRepeat: [count := count + 1]] timeToRun. 139971 (results are in microseconds) So maybe there's a case for inlining #timesRepeat: (or making a clear comment that it is much slower in Pharo) Just my $0:02 -- Cheers, Peter On Fri, Nov 13, 2009 at 9:59 AM, Marcus Denker den...@acm.org wrote: On Nov 13, 2009, at 9:51 AM, Cédrick Béler wrote: Hi, I noticed quite a difference between the two method who looks the same to me. Is it normal ? Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas timesRepeat: is a message send with a closure activation. Marcus fun is the difference between: (1 to : 1) do: and 1 to: 1 do: one is compiled to jumps, the other not and in addition creates a temp collection. Marcus I use a rc image (haven't tested in squeak). And it's the same on windows and linux. count := 0. [1 to: 1000 do: [:i | count :=count + 1]] timeToRun. 677 count := 0. [1000 timesRepeat: [count := count + 1]] timeToRun 2571 If not normal, I'll open a issue. Thanks -- Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?
+1 for making an inlined version of #timesRepeat: Sometimes speed matters, and for someone coming from an environment where it's faster than #to:do: it might not be so easy to detect where the unexpected time penalty came from. Unfortunately, I'm not sufficiently familiar with the Compiler/Decompiler to volunteer to do it myself :-p And to answer Cédrick's question, browsing senders of a method should tell you if it's inlined of not. In VA there are no senders of #timesRepeat: or #to:do, although both are used extensively. In case anyone is interested, here is the complete list of inlined methods in VA #== #~~ #and: #ifFalse: #ifFalse:ifTrue: #ifTrue: #ifTrue:ifFalse: #isNil #not #notNil #or: #timesRepeat: #to:do: #whileFalse: #whileTrue: How does it compare to Pharo? -- Cheers, Peter 2009/11/13 Cédrick Béler cdric...@gmail.com Thanks all. Interesting. I saw by using tallySends that: timesRepeat: This simulation took 6.0 seconds. **Tree** 1 SmallInteger(Integer)timesRepeat: **Leaves** 11 UndefinedObjectDoIt 1 SmallInteger(Integer)timesRepeat: 1 UndefinedObjectDoIt to:do: This simulation took 3.0 seconds. **Tree** **Leaves** 1 UndefinedObjectDoIt I guess this is one consequence of being inlined. This makes ask another questions: -how to know what's inlined, what method have suche properties (a comment would be cool, so if we had to choose...) ? -how to add Compiler inlining rules (as it's easy ;) ) ? -why not inlining timesRepeat: (as I guess we don't really change it often) ? Thanks. ps: the result is slow because I used a 5 year old (at least) computer :). I think I got a 10x difference in a 2 year one... 2009/11/13 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com There is also a difference between: [self atEnd ifTrue: [^nil]. self next. true] whileTrue. and: [self atEnd ifTrue: [^nil] self next] repeat. Warning: it's quite easy to add Compiler inlining rules, a bit tougher to add corresponding Decompiler tricks. 2009/11/13 Marcus Denker den...@acm.org: On Nov 13, 2009, at 9:51 AM, Cédrick Béler wrote: Hi, I noticed quite a difference between the two method who looks the same to me. Is it normal ? Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas timesRepeat: is a message send with a closure activation. Marcus fun is the difference between: (1 to : 1) do: and 1 to: 1 do: one is compiled to jumps, the other not and in addition creates a temp collection. Marcus I use a rc image (haven't tested in squeak). And it's the same on windows and linux. count := 0. [1 to: 1000 do: [:i | count :=count + 1]] timeToRun. 677 count := 0. [1000 timesRepeat: [count := count + 1]] timeToRun 2571 If not normal, I'll open a issue. Thanks -- Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cédrick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Underscore assignments
+1 -- Cheers, Peter On Wed, Nov 4, 2009 at 9:25 AM, Lukas Renggli reng...@gmail.com wrote: I wonder if we should throw a deprecated message in Pharo 1.0 when somebody tries to compile a method with an underscore assignment? I would like to make it possible to use underscore characters in selectors and identifiers in Pharo 1.1. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] 1.0 #10439
I guess this should be 10493, right? /Peter On Tue, Nov 3, 2009 at 10:37 PM, Adrian Lienhard a...@netstyle.ch wrote: - remove tests that depend on current font choice - Issue 1331: DNU upon file-in of changeset - Issue 1398: Seaside loading via ScriptManager broken ___ http://www.adrian-lienhard.ch/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Assignment operator in new core packages
Isn't there a test case for this, or similar coding customs? In my day job we have some, and they are most useful for detecting misses like that. If anyone thinks it's a good idea I could write one, then this kind of problem shouldn't turn up again the future. -- Cheers, Peter 2009/9/30 Torsten Bergmann asta...@gmx.de Classes like SHA1 (now included in core) use _ again instead of := Shouldnt we clean up such packages? Thx T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
