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

Re: [Pharo-project] Issue 3351 in pharo: Comments in MIMEDocument erroneously refer to MIMEObject

by pharo＠googlecode.com

Comment #2 on issue 3351 by tony.fleig: Comments in MIMEDocument erroneously refer to MIMEObject http://code.google.com/p/pharo/issues/detail?id=3351 contentType: aMIMEType content: content "create a MIMEObject with the given content-type and content" "MIMEObject contentType: 'text/plain' content: 'This is a test'"

Nov. 28, 2010

[Pharo-project] Block semantics ....

by James Ladd

Hi All, I'm wondering about documentation to describe the block semantics of Pharo Smalltalk, Specifically around the return context when a block contains a return: [ ^ foo ] Is a block valid only within the method that defined it and passed / called it? I think it is, and when called outside of the context there is a BlockContext no longer exists error. However, I'm looking for documentation or confirmation to ensure my testing was correct. Rgs, James.

Nov. 28, 2010

[Pharo-project] Issue 3352 in pharo: Proposal (with code) for adding multipart/alternative MIME support to MailMessage and WAEmailMessage

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3352 by tony.fleig: Proposal (with code) for adding multipart/alternative MIME support to MailMessage and WAEmailMessage http://code.google.com/p/pharo/issues/detail?id=3352 Pharo image: Pharo Pharo core version: 1.1-11411 Virtual machine used: n/a Class browser used (if applicable): n/a I added the attached methods to MailMessage and modified one method in WAEmailMessage to allow me to create and send multipart/alternative and multipart/mixed email messages from Pharo/Seaside. My need was to send text/plain and text/html multipart/alternative messages for account registration confirmation. SUnit tests are included for all the new methods. I don't know precisely how to contribute this code. I have signed no agreement yet. I'm hoping that by posting it the feature may find its way into Pharo at some point. If the code is unacceptable for some reason, I am willing to make whatever changes are needed. Example using the new functionality: | msg ssmsg | msg := TFMailMessage empty. msg addAlternativePart: 'This is plain text.' contentType: 'text/plain'; addAlternativePart: '<html><head></head><body>This is html.</body></html>' contentType: 'text/html'. ssmsg := msg seasideMailMessageFrom: 'fleig(a)mailserver.com' to: 'example(a)mailserver.com' subject: 'Test multipart message'. ssmsg plainMessage. Produces: 'From: fleig(a)mailserver.com To: example(a)mailserver.com Subject: Test multipart message Date: Sun, 28 Nov 2010 12:46:18 -0800 content-type: multipart/alternative;boundary="==CelesteAttachment50460==" mime-version: 1.0 --==CelesteAttachment50460== Content-type: text/plain This is plain text. --==CelesteAttachment50460== Content-type: text/html <html><head></head><body>This is html.</body></html> --==CelesteAttachment50460==-- ' Attachments: MailMessage-addAlternativePart.st 257 bytes MailMessage-seasideMailMessageFromtosubject.st 578 bytes MailMessage-makeMultipartwith.st 888 bytes WAStringEmailBodyTest-testMultipart.st 1.4 KB MailMessage-addPartcontentType.st 446 bytes MailMessage-addMixedPartcontentType.st 456 bytes MailMessage-addAlternativePartcontentType.st 468 bytes MailMessage-addMixedPart.st 243 bytes

Nov. 28, 2010

Re: [Pharo-project] Issue 3351 in pharo: Comments in MIMEDocument erroneously refer to MIMEObject

by pharo＠googlecode.com

Comment #1 on issue 3351 by stephane.ducasse: Comments in MIMEDocument erroneously refer to MIMEObject http://code.google.com/p/pharo/issues/detail?id=3351 Thanks Can you provide the comment? Accurate comments are important. Thanks for the reporting.

Nov. 28, 2010

Re: [Pharo-project] SqueakSource is down

by StÃ©phane Ducasse

+1 I probably killed it with some heavy changes. :( David I'm really chasing inria to create a secure webdav to host a new squeak-source (but there are security problem is some of their infrastructure and they told me that they should fix that first). We got the hudson server up and running with slaves. > Can someone please wake it up? Thanks. > >

Nov. 28, 2010

Re: [Pharo-project] <script language="smalltalk">

by Mirko Kiefer

I think these are very valid points. The main problem is not dealing with Javascript itself but the fact that it is _different_ to your server side code. During the last months I've extensively been using Javascript on both the client and the server-side and must say that it is a very pleasing experience. It actually shares many similarities with Smalltalk, like the fact that both are very functional languages. Google's V8 Javascript engine actually evolved out of a Smalltalk VM. In the end it isn't much more than syntax that differs both. There is a very vibrant community on the rise, involved in projects like Node.js and CouchDB. Especially event driven programming in Node.js will blow you away when you actually sit down and do some coding with it. I am convinced that these projects really have what it takes to replace a lot of the horribly bloated technology in the software world. A Smalltalk VM as a browser plugin certainly wouldn't have a future. To estimate the effort of writing a Smalltalk Interpreter in Javascript you may want to talk to the guys behind Cappuccino - http://cappuccino.org/ They left Apple and reimplemented Objective-C in the browser, including most of the Cocoa frameworks. You can write some pretty impressing apps using Cappuccino: http://280slides.com/ On 11/28/10 9:17 PM, Igor Stasenko wrote: > On 28 November 2010 19:41,<csrabak(a)bol.com.br> wrote: >> Em 26/11/2010 16:25, Janko MivÅ¡ek< janko.mivsek(a)eranova.si> escreveu: >>> On 26. 11. 2010 18:20, csrabak(a)bol.com.br wrote:> Em 24/11/2010 >>> 11:50, Jan van de Sandt< jvdsandt(a)gmail.com> escreveu: >>> >>>>> A Smalltalk variant would use Smalltalk as the source language >>>>> instead of Java, the other parts of GWT can be reused. GWT is >>>>> open source (Apache 2.0 license). >>>> I think we have first to evaluate to what audience/market are >>>> thinking of targeting this effort, then estimate the effort, in >>>> order to see if its worth it. >>> Specially we the web guys are very interested of such a beast, >>> because we need to develop more in more on the client side and in >>> JavaScript, which is a bit hard, because of our Smalltalk habits, >>> you know :) >> I _do_. However, it is also a major trend "in this vital industry"Â¹ the >> increase in restrictions on the client side leading a lot of developers >> to switch from Javascript (client side computing) to PHP (server side >> computing), for an example of a popular site which ostensibly writes it >> in its home page, look at: http://www.quantitativeskills.com/sisa/Â² >> > same problem again: why doing things twice (write same things in > javascript on client side, > and then rewrite same thing in PHP on server side). Why, i am asking, > why server and client side have to > use different languages? Why industry created such ridiculous > standards, which forcing us to use multiple languages > depending on environment? > A CouchDB, for example, by default supports javascript as a scripting > language for views on server. > This means, that people to build their site& persistency, have to > know only single language - javascript. No PHP, > no SQL and other rusty pieces of technology. :) > >> "Security" reasons plus less acquaintance with a newer technology would >> make this entry in the market very hard in today's environments. >> >> Perhaps what's _really_ needed is a good Javascript debugger? >> > perhaps. And Self-like object's inspectors and explorers :) > >>> Even more, Smalltalk on the client (Clamato way) can also solve one >>> of the main JavaScript problems: debugging on the client side. If we >>> can have near the same debugger on the client as we have in our >>> IDE's, well, this would be a huge step forward. >> For a very small community of Smalltalk developers, yes. What I rose >> earlier and maintain for discussion is if we have critical mass to reap >> the rewards of such an effort: we may end in some sort of the Armstrong's >> words backwards: "It was a huge step forward for Smalltalkers but a non >> movement forward at all for the majority of web developers." >> >>>> If the attempt is a reinterpretation a Smalltalk base development >>>> environment would make a difference in the ecosystem we must check >>>> if we aren't flared by our preference of languages versus >>>> operational pragmatics. >>>> If the idea is to have such environment to the present (and sadly >>>> minute) community of Smalltalk developers, probably the effort >>>> would attend to a very small clientÃ¨le and the returns will be >>>> elusive and the project will end orphan. >> So, rephrasing my point above: except if we can produce those artifacts >> as a simple consequences of subclassing some objects in our environments >> and having a robust enough usable system, we rather consider carefully >> the use of our efforts in other areas where the fruits are hanging lower. >> > Yes, i agree. Such plugin would require a big efforts to complete. > And while from tech side, we can foresee the benefits, from market > side, this is not obvious. > Because niche is already filled by javascript, which is also dynamic > language and very powerful one. > What lacking, is a development environment for javascript, which can > be used to develop things > as same pace as in smalltalk dev environment. > >> -- >> Cesar Rabak >> >> [1] To whom may be missing: it is a pun with a phrase of one of the >> woodpecker shows where a line guard says these words when Woody installs >> himself in one of the telegraph poles.... :-D >> >> [2] Their arguments about mobile devices are also IMNSHO compelling. >> >> > >

Nov. 28, 2010

[Pharo-project] Added issue 3351: Comments in MIMEDocument erroneously refer to MIMEObject

by Tony Fleig

Pharo image: Pharo Pharo core version: 1.1-11411 Virtual machine used: n/a Class browser used (if applicable): n/a In the following method, comments refer to MIMEObject (which I assume is an earlier name for MIMEDocument): MIMEDocument class>>#contentType:content I realize this is a small thing, but it did cause me to hunt around for MIMEObject for a while.

Nov. 28, 2010

[Pharo-project] Issue 3351 in pharo: Comments in MIMEDocument erroneously refer to MIMEObject

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3351 by tony.fleig: Comments in MIMEDocument erroneously refer to MIMEObject http://code.google.com/p/pharo/issues/detail?id=3351 Pharo image: Pharo Pharo core version: 1.1-11411 Virtual machine used: n/a Class browser used (if applicable): n/a In the following method, comments refer to MIMEObject (which I assume is an earlier name for MIMEDocument): MIMEDocument class>>#contentType:content I realize this is a small thing, but it did cause me to hunt around for MIMEObject for a while.

Nov. 28, 2010

Re: [Pharo-project] <script language="smalltalk">

by Mirko Kiefer

On 11/27/10 3:33 AM, Igor Stasenko wrote: > 2010/11/26 Janko MivÅ¡ek<janko.mivsek(a)eranova.si>: >> On 26. 11. 2010 18:20, csrabak(a)bol.com.br wrote: >>> Em 24/11/2010 11:50, Jan van de Sandt< jvdsandt(a)gmail.com> escreveu: >>>> A Smalltalk variant would use Smalltalk as the source language >>>> instead of Java, the other parts of GWT can be reused. GWT is open >>>> source (Apache 2.0 license). >>> I think we have first to evaluate to what audience/market are thinking of >>> targeting this effort, then estimate the effort, in order to see if its >>> worth it. >> Specially we the web guys are very interested of such a beast, because >> we need to develop more in more on the client side and in JavaScript, >> which is a bit hard, because of our Smalltalk habits, you know :) >> >> Even more, Smalltalk on the client (Clamato way) can also solve one of >> the main JavaScript problems: debugging on the client side. If we can >> have near the same debugger on the client as we have in our IDE's, well, >> this would be a huge step forward. >> > indeed. debugging JS is hard. Most of the times, all you can do is to > put 'alert(...)' > in interesting places, to see what's going wrong. > But there are things, like > http://www.mozilla.org/projects/venkman/ > didn't tried it. > Igor, I recommend having a look at the build in developer tools in Safari or Google Chrome (they are the same). They give you a very powerful debugging and profiling environment and the option to inspect all Javascript objects on runtime. On the debugging side there is actually very little that you would miss from Pharo. >>> If the attempt is a reinterpretation a Smalltalk base development environment >>> would make a difference in the ecosystem we must check if we aren't flared >>> by our preference of languages versus operational pragmatics. >>> >>> If the idea is to have such environment to the present (and sadly minute) >>> community of Smalltalk developers, probably the effort would attend to a >>> very small clientÃ¨le and the returns will be elusive and the project will >>> end orphan. >> -- >> Janko MivÅ¡ek >> AIDA/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >> > >

Nov. 28, 2010

Re: [Pharo-project] <script language="smalltalk">

by Igor Stasenko

On 28 November 2010 19:41, <csrabak(a)bol.com.br> wrote: > Em 26/11/2010 16:25, Janko MivÅ¡ek < janko.mivsek(a)eranova.si > escreveu: >> On Â 26. 11. 2010 Â 18:20, csrabak(a)bol.com.br Â wrote: > Â Em 24/11/2010 >> 11:50, Jan van de Sandt < jvdsandt(a)gmail.com > escreveu: >> >> >> A Smalltalk Â variant would use Â Smalltalk as the Â source language >> >> instead of Â Java, the other Â parts of GWT Â can be reused. Â GWT is >> >> open source (Apache 2.0 license). >> >> > I Â think we Â have first Â to evaluate Â to what Â audience/market are >> > thinking of Â targeting this effort, Â then estimate the Â effort, in >> > order to see if its worth it. >> Â Specially Â we the web Â guys are Â very interested Â of such Â a beast, >> because we Â need to develop more in Â more on the client Â side and in >> JavaScript, which Â is a bit Â hard, because of our Â Smalltalk habits, >> you know :) > > I _do_. However, it is also a major trend "in this vital industry"Â¹ the > increase in restrictions on the client side leading a lot of developers > to switch from Javascript (client side computing) to PHP (server side > computing), for an example of a popular site which ostensibly writes it > in its home page, look at: http://www.quantitativeskills.com/sisa/Â² > same problem again: why doing things twice (write same things in javascript on client side, and then rewrite same thing in PHP on server side). Why, i am asking, why server and client side have to use different languages? Why industry created such ridiculous standards, which forcing us to use multiple languages depending on environment? A CouchDB, for example, by default supports javascript as a scripting language for views on server. This means, that people to build their site & persistency, have to know only single language - javascript. No PHP, no SQL and other rusty pieces of technology. :) > "Security" reasons plus less acquaintance with a newer technology would > make this entry in the market very hard in today's environments. > > Perhaps what's _really_ needed is a good Javascript debugger? > perhaps. And Self-like object's inspectors and explorers :) > >> Â Even more, Smalltalk on the client (Clamato way) can also solve one >> of the main JavaScript problems: debugging on the client side. If we >> can have Â near the Â same debugger on Â the client Â as we have Â in our >> IDE's, well, this would be a huge step forward. > > For a very small community of Smalltalk developers, yes. Â What I rose > earlier and maintain for discussion is if we have critical mass to reap > the rewards of such an effort: we may end in some sort of the Armstrong's > words backwards: "It was a huge step forward for Smalltalkers but a non > movement forward at all for the majority of web developers." > >> >> > If the attempt is Â a reinterpretation a Smalltalk base development >> > environment would make a difference in the ecosystem we must check >> > if Â we Â aren't Â flared Â by Â our Â preference Â of Â languages Â versus >> > operational pragmatics. >> > If the idea is to have Â such environment to the present (and sadly >> > minute) Â community of Â Smalltalk developers, Â probably Â the effort >> > would attend Â to a Â very small clientÃ¨le Â and the returns Â will be >> > elusive and the project will end orphan. > > So, rephrasing my point above: except if we can produce those artifacts > as a simple consequences of subclassing some objects in our environments > and having a robust enough usable system, we rather consider carefully > the use of our efforts in other areas where the fruits are hanging lower. > Yes, i agree. Such plugin would require a big efforts to complete. And while from tech side, we can foresee the benefits, from market side, this is not obvious. Because niche is already filled by javascript, which is also dynamic language and very powerful one. What lacking, is a development environment for javascript, which can be used to develop things as same pace as in smalltalk dev environment. > -- > Cesar Rabak > > [1] To whom may be missing: it is a pun with a phrase of one of the > woodpecker shows where a line guard says these words when Woody installs > himself in one of the telegraph poles.... :-D > > [2] Their arguments about mobile devices are also IMNSHO compelling. > > -- Best regards, Igor Stasenko AKA sig.

Nov. 28, 2010