- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Investigating MultiByteFileStream for adding tests

by Stephan Eggermont

Sheridan wrote: >Do operations involving FileStream as input always return a >MultiByteFileStream? That is a well-known pattern, class cluster. A base class defining an interface and acting as a factory hiding the specific class returned. Cocoa uses that a lot, it results in a much cleaner architecture than that of .net and java. https://developer.apple.com/library/ios/documentation/General/Conceptual/Co… Stephan

Dec. 8, 2014

Investigating MultiByteFileStream for adding tests

by sheridan＠sheridan-mahoney.com

Hi, I've been looking into MultiByteFileStream for adding tests in this area, and have come up against what appears to me to be an anomaly. I ran the following 4 tests: FileStream fileNamed: 'test.txt' do: [ :str | str nextPutAll: '123'; crlf ]. MultiByteFileStream fileNamed: 'test2.txt' do: [ :str | str nextPutAll: '123'; crlf ]. FileStream fileNamed: 'test3.txt' do: [ :str | str nextPutAll: 'Ã©lÃ¨ve en FranÃ§ais'; crlf ]. MultiByteFileStream fileNamed: 'test4.txt' do: [ :str | str nextPutAll: 'Ã©lÃ¨ve en FranÃ§ais'; crlf ]. The results are: Input string Result Unix File Class Class Type --------------------------------------------------------------- FileStream '123' MultiByte- ASCII text FileStream MultiByte- '123' MultiByte- ASCII text FileStream FileStream FileStream 'Ã©lÃ¨ve en MultiByte- UTF-8 Unicode FranÃ§ais' FileStream MultiByte- 'Ã©lÃ¨ve en MultiByte- UTF-8 Unicode FileStream FranÃ§ais' FileStream Do operations involving FileStream as input always return a MultiByteFileStream? Thanks, Sheridan

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Tudor Girba

Hi, We do not yet have an IDE (where I stands for integrated). We have a set of tools and some of them are quite strong. But, we do not have an overall experience yet. Yes, the underlying language model does offer a beautiful experience, but the experience of the tools is far from that. We need tools that are not just powerful in the hands of few specialists, but tools that are beautiful and pleasurable to use in the hands of many. This is the goal. When we will get that, I believe we will change the game. Cheers, Doru On Mon, Dec 8, 2014 at 9:36 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > "Our "battle" is with the non-Smalltalk world. This is what we need to > convince. And that world does not care about the history of Smalltalk. It > cares about how we can solve their problem. That's all." > > But you already offer an impressive arsenal of tools. The world can > complain for several things but what it cannot complain is that Pharo as an > IDE is not really powerful as a whole. Your competition would be I assume > specialised tools that come as third party. There is no IDE I know out > there that offers the level of refactoring of Pharo, in terms of tools and > libraries. > > Also we should not forget that those tools are not just powerful as is the > example of GTPlayground but are engineered in such way to cooperate which > each other with ease. While on the other hand , tools for other programming > languages are by default separate and independent and not necessarily play > nice with each other which the price one pays to keep things modular and > unattached to a specific language or IDE. So the way I see it Pharo already > is beyond competition. > > Unless of course you refer to a comparison tool per tool, which mean you > take this pharo tool and you compare with another tool for another language > out there. That case would very difficult for you because there are tons of > development tools out there. > > But the overall idea that is "hey there I give you a language, take this > enviroment too, live coding, how about an IDE and also get these coding > tools too " is really a dreamy situation already. > > The question is how badly coders want a very powerful IDE at least the > level of Pharo. > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by kilon alios

"Our "battle" is with the non-Smalltalk world. This is what we need to convince. And that world does not care about the history of Smalltalk. It cares about how we can solve their problem. That's all." But you already offer an impressive arsenal of tools. The world can complain for several things but what it cannot complain is that Pharo as an IDE is not really powerful as a whole. Your competition would be I assume specialised tools that come as third party. There is no IDE I know out there that offers the level of refactoring of Pharo, in terms of tools and libraries. Also we should not forget that those tools are not just powerful as is the example of GTPlayground but are engineered in such way to cooperate which each other with ease. While on the other hand , tools for other programming languages are by default separate and independent and not necessarily play nice with each other which the price one pays to keep things modular and unattached to a specific language or IDE. So the way I see it Pharo already is beyond competition. Unless of course you refer to a comparison tool per tool, which mean you take this pharo tool and you compare with another tool for another language out there. That case would very difficult for you because there are tons of development tools out there. But the overall idea that is "hey there I give you a language, take this enviroment too, live coding, how about an IDE and also get these coding tools too " is really a dreamy situation already. The question is how badly coders want a very powerful IDE at least the level of Pharo.

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by HernÃ¡n Morales Durand

Hello Doru, I think you have a new different implementation of the classic Workspace, for better or worst. The problem is everybody wants their tool be named as the highest taxonomic rank. Compare it with naming your cat as "Cat" and not as Siamese Felis Catus which is a specific breed. On the other side, what prevents for anyone else doing a "better"/new implementation and reclaiming the Workspace name? And this could happen every year? I don't know you but I get bored of seeing "I want that name" discussions. Workspace is a type of tool, it happens that there is an implementation which owned such name. It should be renamed as OldWorkspace, DeveloperWorkspace, ClassicWorkspace, or whatever. For me, Workspace in the World menu should display a sub-menu with both implementations. And community gains a place to display/register more implementations discriminated by its type. HernÃ¡n 2014-12-08 3:18 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > As you might see, the GTPlayground is called playground not workspace. The > main reason for this is that workspace implies the place where work is > done, and work is typically associated with creating code. > > This is not the intention of the workspace. > > Workspace also comes with a history that is associated with actual > implementations. While the current GTPlayground might appear to be similar > to the workspace, I think the way you can use the latter produces a > significant shift. > > Furthermore, I think the term playground is more inline with the idea of > "playing with live objects". And, in the future, the implementation will > likely evolve towards even more liveliness. > > It is for this reason that I would prefer that the World menu item gets > renamed to Playground. > > What do you think? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Dec. 8, 2014

Re: [Pharo-dev] [squeak-dev] Does Monticello try to install shared pools before methods using them?

by Chris Muller

I'm pretty sure the responsibility falls to the loader. I'm not too familiar with it but if I wanted to be I would probably start tracing from McVersionLoader. Do your pool references end up being valid? That is the most important but I agree it would be an annoyance to see those messages in the Transcript. On Mon, Dec 8, 2014 at 7:24 AM, Craig Latta <craig(a)netjam.org> wrote: > > Hoi-- > > I'm attempting to create a Monticello package which provides a > shared pool (as a subclass of SharedPool) and methods which use its > variables. On installation, does Monticello try to ensure that a pool is > installed before methods which use it? When I install the package in a > fresh system, I get messages on the Transcript complaining that shared > variables are undefined. > > Is there some way one fiddles with the writing process, or with the > package after it is written, to avoid ordering problems? > > > thanks! > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Andreas Wacknitz

> Am 08.12.2014 um 20:36 schrieb Andreas Wacknitz <a.wacknitz(a)gmx.de>: > > >> Am 08.12.2014 um 20:27 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi Andreas, >> >> With all due respect for the other Smalltalk (inspired or genuine) environments, I have no intention of waiting for them in order to define the way forward. > Itâs not about respect for the other Smalltalk environments but for those who work sometimes outside the Pharo world. And you donât have to wait for anybody. We are talking about the name and not the features. > As I said: the changes donât justify a new name in my eyes. For me what you call GTPlayground is a better workspace than the original one. It will replace the workspace (in Pharo) for me > but it is still a workspace. > >> >> Our "battle" is with the non-Smalltalk world. This is what we need to convince. And that world does not care about the history of Smalltalk. It cares about how we can solve their problem. That's all. >> > My experience is that the non-Smalltalk ignorant and GTPlayground, as good as it is, will not convince many people. Itâs simply too low-level. Hm, I should have proof read this before hitting the send button: My experience is that the (non-Smalltalk) world is ignorantâ¦ > > Regards > Andreas > >> Cheers, >> Doru > >

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Andreas Wacknitz

> Am 08.12.2014 um 20:27 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Andreas, > > With all due respect for the other Smalltalk (inspired or genuine) environments, I have no intention of waiting for them in order to define the way forward. Itâs not about respect for the other Smalltalk environments but for those who work sometimes outside the Pharo world. And you donât have to wait for anybody. We are talking about the name and not the features. As I said: the changes donât justify a new name in my eyes. For me what you call GTPlayground is a better workspace than the original one. It will replace the workspace (in Pharo) for me but it is still a workspace. > > Our "battle" is with the non-Smalltalk world. This is what we need to convince. And that world does not care about the history of Smalltalk. It cares about how we can solve their problem. That's all. > My experience is that the non-Smalltalk ignorant and GTPlayground, as good as it is, will not convince many people. Itâs simply too low-level. Regards Andreas > Cheers, > Doru

Dec. 8, 2014

Re: [Pharo-dev] playground vs workspace

by Tudor Girba

Hi Andreas, With all due respect for the other Smalltalk (inspired or genuine) environments, I have no intention of waiting for them in order to define the way forward. Our "battle" is with the non-Smalltalk world. This is what we need to convince. And that world does not care about the history of Smalltalk. It cares about how we can solve their problem. That's all. Cheers, Doru On Mon, Dec 8, 2014 at 8:21 PM, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > > Am 08.12.2014 um 07:18 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > > > Hi, > > > > As you might see, the GTPlayground is called playground not workspace. > The main reason for this is that workspace implies the place where work is > done, and work is typically associated with creating code. > For me GTPlayground is a replacement of the workspace. At the moment this > is obviously so: the workspace menu item has been replaced by the one for > the Playground. > The term Workspace is widely known in the Smalltalk community. Donât > change the name just because you put some enhancements to it. > > > > > This is not the intention of the workspace. > > > > Workspace also comes with a history that is associated with actual > implementations. While the current GTPlayground might appear to be similar > to the workspace, I think the way you can use the latter produces a > significant shift. > > > > Furthermore, I think the term playground is more inline with the idea of > "playing with live objects". And, in the future, the implementation will > likely evolve towards even more liveliness. > > > > It is for this reason that I would prefer that the World menu item gets > renamed to Playground. > > > > What do you think? > I like the enhancements but I donât like the new name. Only time will tell > if the ideas of GTPlayground will be adapted by other Smalltalks and then > it would be the right time to talk about a better name than workspace. > > Regards > Andreas > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 8, 2014

Re: [Pharo-dev] Excel binding

by blake

You could probably do it with Redline Smalltalk via Apache POI. On Mon, Dec 8, 2014 at 6:22 AM, Blondeau Vincent < vincent.blondeau(a)worldline.com> wrote: > Hi, > > > > Does someone know if there is a mean to access Excel sheets from Pharo to > get data? > > I donât want to use .csv files but .xls/.xlsx files. > > > > Thanks in advance > > > > Cheers, > > > > Vincent BLONDEAU > > > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Dec. 8, 2014