December 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SqueakSource is down

by Fabrizio Perin

it up 2010/12/2 Stanislav Paskalev <kshorg(a)gmail.com> > Stanislav Paskalev > >

Dec. 2, 2010

[Pharo-project] SqueakSource is down

by Stanislav Paskalev

Stanislav Paskalev

Dec. 2, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by csrabak＠bol.com.br

Em 01/12/2010 18:50, Tudor Girba <tudor.girba(a)gmail.com> escreveu: > Hi, > I think I understand your point of view, but I do not agree with it > :). Fair enough! During a debate automatic agreement would not lead to an enriched vision of the problem and more often than not would diverge from the truth :-) > Moose is a valuable platform exactly because it is built in > Smalltalk. I understand this is the sentiment about Smalltalk. Also, giving the project is 13+ years old makes me assume it has started in a different dialect of Smalltalk than Pharo. > Developers understand the power of Smalltalk in the > context of Moose quite quickly after they do a couple of > tutorials. The key here, I think, is "in the context of Moose". In my opinion the litmus test for this would be evaluating how many projects _not_ related to Moose are started in Smalltalk after this exposition occurred. > The result is that they end up wanting to learn > Smalltalk. Which per se is an interesting achievement. However, we need it go beyond the wanting to learn to the opportunity to be the implementation language of some new projects in their realms. > In fact, I argued for quite a while that vendors should use Moose > to promote Smalltalk. The cool thing about it is that it addresses > directly programmers that develop in all sorts of languages > (especially Java). This gives us a nice back door. I think again this is a variation of theme I mentioned in the earlier post. The same has been said about Seaside, or other projects which I perceive as successful as Moose (and written in Smalltalk, of course)! I'm afraid we're missing something essential on this: what problem Pharo (or more generally Smalltalk) addresses better in the enterprise than other technologies? If we arrive at some compelling answers to this, then I believe it would be easy to 'sell' Smalltalk. The examples on the successful projects then would serve to reduce the perceived risk of embarking in an imature technology. my 0.019999... Regards, -- Cesar Rabak > Cheers, Doru > > On 28 Nov 2010, at 18:48, csrabak(a)bol.com.br wrote: > > > Tudor, > > This kind of report shows that Moose is a useful piece of > > software. The interest in Pharo became contingent on the Moose > > technology such as ABAP is 'widespread' in the industry because of > > SAP ERP. > > I think it says a lot about Moose, but is not enough to be a sales > > argument for Pharo. > > This leads to a common fallacy used in marketing: use "X" as all > > successful people use "X" as well..." > >

Dec. 2, 2010

Re: [Pharo-project] Changesets with LF/CRLF instead of CR?

by Stefan Marr

Here a quick hack, in case anyone cares: 'From Pharo1.2a of ''11 June 2010'' [Latest update: #12261] on 1 December 2010 at 10:42:06 pm'! !FileStream class methodsFor: 'file reader services' stamp: 'StefanMarr 12/1/2010 22:42'! writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag | extension converter fileName lineEndConvention | lineEndConvention := MultiByteFileStream guessDefaultLineEndConvention. lineEndConvention := MultiByteFileStream lineEndConventionAsString: lineEndConvention. extension := stOrCsFlag ifTrue: ['.st'] ifFalse: ['.cs']. converter := aStream contents isAsciiString ifTrue: [MacRomanTextConverter new] ifFalse: [UTF8TextConverter new]. converter installLineEndConvention: lineEndConvention. fileName := baseName, extension. fileName := FileDirectory default checkName: fileName fixErrors: true. [FileStream newFileNamed: fileName do: [:fileStream | (converter isMemberOf: UTF8TextConverter) ifTrue: [fileStream binary. UTF8TextConverter writeBOMOn: fileStream]. fileStream text; converter: converter; nextPutAll: aStream contents; close]] on: Abort do: [:e | ]! ! !MultiByteFileStream class methodsFor: 'class initialization' stamp: 'StefanMarr 12/1/2010 22:39'! defaultToCR "MultiByteFileStream defaultToCR" LineEndDefault := #cr. ^ LineEndDefault! ! !MultiByteFileStream class methodsFor: 'class initialization' stamp: 'StefanMarr 12/1/2010 22:39'! defaultToCRLF "MultiByteFileStream defaultToCRLF" LineEndDefault := #crlf. ^ LineEndDefault! ! !MultiByteFileStream class methodsFor: 'class initialization' stamp: 'StefanMarr 12/1/2010 22:39'! defaultToLF "MultiByteFileStream defaultToLF" LineEndDefault := #lf. ^ LineEndDefault ! ! !MultiByteFileStream class methodsFor: 'class initialization' stamp: 'StefanMarr 12/1/2010 22:36'! lineEndConventionAsString: conventionSymbol ^ LineEndStrings at: conventionSymbol ! ! On 30 Nov 2010, at 14:06, Stefan Marr wrote: > Hi: > > On 30 Nov 2010, at 13:56, Schwab,Wilhelm K wrote: > >> A possible wrinkle: what about using Linux to write a file for a Windows user? > That is why I proposed to use MultiByteFileStream LineEndDefault. > > There are methods in MultiByteFileStream to set it explicitly. So, it could be either set in a save dialog, or a user preference somewhere, I guess. > > Best regards > Stefan > > PS: The file stream should be initialized on creation with MultiByteFileStream LineEndDefault, otherwise it is not thread/RoarVM-safe... > >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stefan Marr [pharo(a)stefan-marr.de] >> Sent: Tuesday, November 30, 2010 7:13 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Changesets with LF/CRLF instead of CR? >> >> Hello: >> >> On 30 Nov 2010, at 09:20, StÃ©phane Ducasse wrote: >> >>> as a general principle, I'm open to change for the better :) >>> Now how much? >>> - cost to do >> Cleaning it up completely does not looks like a simple/localized change to a single method. >> >> There are 'aFileStream cr' message sends all over the place, which from my perspective are wrong in the sense that they are not platform independent. I guess the best way would be to have something like 'aFileStream nl' or 'lineEnd' instead. Where nl/lineEnd uses MultiByteFileStream LineEndDefault. >> >> Best regards >> Stefan >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> >> > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Dec. 1, 2010

Re: [Pharo-project] FFI question. Is it possible to unload loaded external library

by Denis Kudriashov

By loaded dll I mean what happens when I call some dll function. After this I can't update this dll. I will try #unloadModule: as Igor adviced 2010/12/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Tue, Nov 30, 2010 at 9:35 PM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > >> Hello, >> >> I need implement remote updating some dll's for running pharo application. >> This dll's used by FFI. >> I want done this by unloading dll from VM. Then loading new updated dll. >> And then continue app execution. >> Is it possible? >> > > what does it mean exactly to "load" a dll and "unload" ?? > cheers > > mariano > > >> >> Or only way is to restart pharo? >> > >

Dec. 1, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by Tudor Girba

Hi, I think I understand your point of view, but I do not agree with it :). Moose is a valuable platform exactly because it is built in Smalltalk. Developers understand the power of Smalltalk in the context of Moose quite quickly after they do a couple of tutorials. The result is that they end up wanting to learn Smalltalk. In fact, I argued for quite a while that vendors should use Moose to promote Smalltalk. The cool thing about it is that it addresses directly programmers that develop in all sorts of languages (especially Java). This gives us a nice back door. Cheers, Doru On 28 Nov 2010, at 18:48, csrabak(a)bol.com.br wrote: > Tudor, > > This kind of report shows that Moose is a useful piece of software. The interest in > Pharo became contingent on the Moose technology such as ABAP is 'widespread' in the > industry because of SAP ERP. > > I think it says a lot about Moose, but is not enough to be a sales argument for Pharo. > > This leads to a common fallacy used in marketing: use "X" as all successful people use "X" as well..." > > -- > Cesar Rabak > > > Em 27/11/2010 07:23, Tudor Girba < tudor.girba(a)gmail.com > escreveu: > Hi, > > I recently introduced Pharo in a small-medium software company (parametrix.ch). They use it for Moose (moosetechnology.org) to analyze their systems written in various languages and to introduce an assessment approach in their day to day development process (humane-assessment.com) A number of them are now learning to program in Pharo and Moose. > > Cheers, > Doru > > > On 26 Nov 2010, at 22:07, laurent laffont wrote: > >> Indeed I don't want a "how to integrate Pharo into enterprise", I want a "actually I have introduce Pharo in my enterprise and why; what works and what doesn't". >> >> Laurent. >> > > -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

Dec. 1, 2010

Re: [Pharo-project] Issue 3361 in pharo: CompiledMethod's copy

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.3 Comment #2 on issue 3361 by stephane.ducasse: CompiledMethod's copy http://code.google.com/p/pharo/issues/detail?id=3361 tx

Dec. 1, 2010

[Pharo-project] [ANN] New Smalltalk VM Beginners mailing list

by Mariano Martinez Peck

Hi everybody. We want to announce that we've created a mailing list called "Smalltalk VM Beginners" where all the people interested in VM can share knowledge. The aim of this mailing list is create a good and positive energy and spread the knowledge around the Squeak VM. If you always wanted to know something on the VM but never dare to ask, join the mailing-list, may be we will not know it but we will try hard to learn it together. The idea is that we can help each other, welcome people to learn about the VM, and increase and share the knowledge about it in the community. Everybody can ask questions, everybody can help. This mailing list has more or less the same idea of pharo-users or squeak-beginners. Now, to clarify the objectives of the mailing list, we propose some requirements: - Be polite, respectful. - No question is stupid and all questions are welcome. We welcome the most basic questions someone can ask about the VM like, "is it written in C?" "How can I download the code?" - This mailing list should be useful for people that are just interested in knowing a little about the VM, to those who want to know how certain things are done, and specially for those that are learning about the VM because they need to extend or modify it. - If you have a heavy question, you will probably not get the answer in this mailing-list but this is not a problem you can ask in the Squeak VM mailing list. - The idea is that we can help each other. So, the link to the mailing list is: http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners Address: vm-beginners(a)lists.squeakfoundation.org. Cheers

Dec. 1, 2010

Re: [Pharo-project] A new GUI visual designer

by Tobias Pape

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2010-12-01 um 16:13 schrieb Igor Stasenko: > On 1 December 2010 12:48, nullPointer <epicfan(a)gmail.com> wrote: >> >> >> https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki… >> >> It really looks very professional. I made a user interface builder for >> Polymorph, which I left because I was too complicated for me. I hope that >> now someone more knowledgeable can really necessary to implement a tool for >> Squeak / Pharo as a visual designer user interfaces. >> > > +1 > that's really important stuff. And this project looks very promising. > Hope, author(s) can shed a light on it, in what stage it is, what > license etc etc. Its all on that wiki. Feel free to contact me, anyways. So Long -Tobias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkz2iCMACgkQcPVIrP6PLKuiowCeNAFhjRdcFFYlxpaVGqHqBGml dkQAoKVVzSy6H6ycRuZw0UXIjAW0uHvY =Pv5I -----END PGP SIGNATURE-----

Dec. 1, 2010

Re: [Pharo-project] [squeak-dev] RE: OSProcess update (was: [OSProcess] Proposal for Pharo 1.2 compatibility)

by David T. Lewis

On Tue, Nov 30, 2010 at 11:24:38PM -0500, Schwab,Wilhelm K wrote: > Dave, > > Does that mean that PipeableOSProcess can load w/o MVC support? That would be great! Yes. The SqS/CommandShell package is split into sub-packages, so you do not need to load CommandShell-MVC if you do not want it. As always, for Squeak images the easiest thing is to just load the latest version of the full OSProcess and CommandShell packages, which are always up to date for Squeak trunk. On Pharo, you may want to skip the MVC package and also load CommandShellPharo if you want menu registration, but otherwise they are the same. The only new information of interest for Squeak is that folks running Cog on Linux should update their OSProcess to the latest version, otherwise OSProcess can crash the VM with X11 protocol errors when attempting a #forkSqueak. > > You've just reminded me that there is a Windows plugin - for a long time, I thought it was necessary to use ProcessWrapper there. I don't have much need for piping on Windows, but one never knows when it might surface again. Is there a binary for the plugin? I find the Linux VM wanting in diagnostic feedback, so I end up hacking and building it from source, but the Windows VM seems to just work as-is; I have not needed to build it for a long time. In fairness, I don't ask much of Windows these days, but I do need to target it. > > Bill > I think that ProcessWrapper is the best way to go for Windows right now. Dave > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] > Sent: Tuesday, November 30, 2010 9:44 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] OSProcess update (was: [OSProcess] Proposal for Pharo 1.2 compatibility) > > To follow up on this, I have now updated both OSProcess and CommandShell > to work on Pharo 1.2. I have not yet had a chance to look at the > Metacello configurations, but loading the latest versions of OSProcess > and CommandShell, and CommandShellPharo from SqueakSource will give > the correct configurations. For CommandShell, ignore the MVC warnings > on load, or you can load the individual sub-packages from SqueakSource > and leave out CommandShell-MVC. > > The separate CommandShellPharo package in SqS/CommandShell provides > world menu registration for opening a command shell morph on Pharo > (open a new command shell morph with world -> Tools -> Command shell). > This is in its own package because of the use of pragmas for menu > registration, which cannot be loaded into some other Squeak images > (e.g. Squeak 3.8 and earlier). > > I note that on Pharo: > TextStyle named: 'DefaultFixedTextStyle' ==> a TextStyle Accuny12(FontSet) > Which seems to be a proportional font rather than fixed, so the font > in a CommandShell window is not as nice as it should be. > > OSProcess and CommandShell test suites are green on Squeak/Unix VM, > but a bit flakey when I run them on Pharo. Issues are timing related, > and I cannot say if they are issues in Pharo, CommandShell, or maybe > just the way I wrote the tests. But for general use, everything seems > to be working now. > > When running on Cog, you should expect #forkSqueak to fail, but it > will no longer crash the VM as in earlier OSProcess versions. However, > #forkSqueak is used extensively in the unit tests for various > multiprocessing test setups, which means that the test suites will > not run properly. That said, most of the rest of OSProcess and > CommandShell should work on Cog. > > Most things should work on a Mac VM, although I cannot personally > verify. Windows support is incomplete and the plugin is not widely > available. > > Dave >

Dec. 1, 2010