April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3598 in pharo: [Failing Test]Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3598 by marcus.d...(a)gmail.com: [Failing Test]Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing http://code.google.com/p/pharo/issues/detail?id=3598 in 13159

April 16, 2011

Re: [Pharo-project] Issue 3598 in pharo: [Failing Test]Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing

by pharo＠googlecode.com

Comment #4 on issue 3598 by marcus.d...(a)gmail.com: [Failing Test]Tests.Compiler.CompilerTest.testNotInteractiveInBlockTempArgumentShadowing http://code.google.com/p/pharo/issues/detail?id=3598 in 13159

April 16, 2011

Re: [Pharo-project] Issue 3872 in pharo: [Failing Test] 1.3 HttpUrlTest.testHttps

by pharo＠googlecode.com

Updates: Status: Closed Comment #6 on issue 3872 by marcus.d...(a)gmail.com: [Failing Test] 1.3 HttpUrlTest.testHttps http://code.google.com/p/pharo/issues/detail?id=3872 (No comment was entered for this change.)

April 16, 2011

Re: [Pharo-project] Issue 3587 in pharo: Clean up handling of WideStrings

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #4 on issue 3587 by marcus.d...(a)gmail.com: Clean up handling of WideStrings http://code.google.com/p/pharo/issues/detail?id=3587 (No comment was entered for this change.)

April 16, 2011

Re: [Pharo-project] Issue 3341 in pharo: use #= for integer comparison instead of #==

by pharo＠googlecode.com

Updates: Status: Started Labels: -Milestone-1.3 Comment #13 on issue 3341 by marcus.d...(a)gmail.com: use #= for integer comparison instead of #== http://code.google.com/p/pharo/issues/detail?id=3341 (No comment was entered for this change.)

April 16, 2011

Re: [Pharo-project] Issue 4030 in pharo: defaultBackgroundColor should not use self theme

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 4030 by marcus.d...(a)gmail.com: defaultBackgroundColor should not use self theme http://code.google.com/p/pharo/issues/detail?id=4030 in 13159

April 16, 2011

[Pharo-project] Status of WebClient for Pharo?

by Friedrich Dominicus

Dear Pharo developers, can you tell me about the status of WebClient in Pharo. (well and if you know it would be nice to know if SqueakSSL is "working", or "working in principal" or "not working.) Or do you have other suggestions for accessing the diverse Web services with Pharo? Regards Friedrich

April 16, 2011

Re: [Pharo-project] Issue 4031 in pharo: Remove "Mail to list" in ChangeSorter

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 4031 by marcus.d...(a)gmail.com: Remove "Mail to list" in ChangeSorter http://code.google.com/p/pharo/issues/detail?id=4031 in 13159

April 16, 2011

[Pharo-project] DYLA @ TOOLS EUROPE'11

by Alexandre Bergel

Hi! Dyla is a successful series of workshop on dynamic languages. As the previous year, It will be collocated with TOOLS EUROPE. The deadline is April 18 for a two-pages submission. http://scg.unibe.ch/wiki/events/dyla2011 Feel free to ask for more details. Regards, Alexandre --------- DYLA @ TOOLS EUROPE'11 July 1, 2011, ZÃ¼rich, Switzerland --------- The DYLA Workshop series focuses on the revival of dynamic languages. These days, dynamic languages (like Lisp, Ruby, Python, JavaScript, Lua, etc...) are getting ever more popular. This is a call to arms for academia! We need to explore the future of dynamic languages through its human aspects and technical issues. We also ought to look back and pick up solutions from existing dynamic languages (such as Scheme, Smalltalk, JRuby, Jython, Groovy, or Self) to be rediscovered and spread around. --------- Goal and Topics --------- The goal of this workshop is to act as a forum where we can discuss new advances in the design, implementation and application of dynamically typed languages that, sometimes radically, diverge from the statically typed class-based mainstream with limited reflective capabilities. Another objective of the workshop is to discuss new as well as older "forgotten" languages and features in this context. Topics of interest include, but are certainly not limited to: Human aspects of dynamic languages, for example... -empirical studies about the application of dynamic languages -best practices and patterns specific to dynamic languages -program correctness through unit testing (as opposed to types) -improved or novel IDE support for dynamic languages -use of dynamic features by library & framework developers -scripting of static application with dynamic languages -reverse engineering and analysis of dynamic applications Technical aspects of dynamic languages, for example... -what features make a language a dynamic one? -agents, actors, active object, distribution, concurrency and mobility -delegation, prototypes, mixins, traits -first-class closures, continuations, environments -reflection and meta-programming -(dynamic) aspects for dynamic languages -higher-order objects & messages -...other exotic dynamic features -multi-paradigm & static/dynamic-marriages -(concurrent/distributed/mobile/aspect) virtual machines -optimisation of dynamic languages -automated reasoning about programs written in dynamic languages - type systems for dynamic languages, pluggable types, partial typing, type reconstruction... And any topic relevant in applying and/or supporting dynamic languages: Smalltalk, Python, Ruby, Javascript, Scheme, Lisp, Self, ABCL, Prolog, Ioke, Clojure and many more... --------- Submissions --------- The workshop will have a demo-oriented style. The idea is to allow participants to demonstrate new and interesting features and discuss what they feel is relevant for the dynamic language community. Participants need to submit a 2-4 page position paper of their work in *ACM sig-alternate.cls>http://www.acm.org/sigs/publications/proceedings-templates* format. At the workshop, participants will be asked to give 10-minute "lightning demos" of their contributions. --------- Important dates --------- -Paper submission deadline: ''April 18, 2011'' -Paper acceptance notification: ''May 14, 2011'' -Camera ready of papers: ''May 31, 2011'' -Camera ready of Workshop Proceedings: ''July 1, 2011'' --------- Organizers --------- -*Alexandre Bergel>http://bergel.eu*, University of Chile, Santiago, Chile -*Carl Friedrich Bolz>http://cfbolz.de*, Heinrich-Heine-Universitaet, Duesseldorf, Germany -*Stephane Ducasse>http://stephane.ducasse.free.fr/*, RMoD Research group, INRIA Lille-Nord Europe, France -*Lukas Renggli>http://www.lukas-renggli.ch/*, Google, Switzerland -*Jorge Ressia>http://www.jorgeressia.com/*, University of Bern, Switzerland --------- Program committee (under construction) --------- -Gabriela Arevalo, University of La Plata, Argentina -Jean-Baptiste Arnaud, RMoD Team, INRIA Lille Nord Europe, France -Alexandre Bergel, University of Chile, Chile -Carl Friedrich Bolz, Heinrich-Heine-Universitaet, Germany -Stephane Ducasse, INRIA Lille Nord Europe, France -Tom van Cutsem, Vrije Universiteit Brussel, Belgium -Tom Dinkelaker, Technische Universitaet Darmstadt -Johan Fabry, University of Chile, chile -Roberto Ierusalimschy, Pontifical University in Rio de Janeiro -James Noble, Victoria University of Wellington, New Zealand -Lukas Renggli, Google, Switzerland -Jorge Ressia, SCG, University of Bern -David Schneider, Heinrich-Heine-Universitaet, Duesseldorf, Germany http://scg.unibe.ch/wiki/events/dyla2011 http://twitter.com/dyla11 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 16, 2011

Re: [Pharo-project] About Zinc to replace HTTPClient

by Norbert Hartl

Am 16.04.2011 um 15:52 schrieb Mariano Martinez Peck: > I have a couple of question, not about Zn but the process: > > 1) Stef, you are talking about just to put Zn in the image or REPLACE all uses of HTTP to use Zn? I would hope so. I think it would be easy to provide a facade with the current API that uses Zinc. > 2) It may be difficult to replace that since Monticello use it -> be carfeul ! If I remember correctly Sven has tested monticello from an early stage on. And it seems to be a reliable thing to use. > 3) How are you going to depreacate HTTP? What do you mean? The HTTP classes in Network-Protocols or http the protocol) :) > 4) Does Zn mantains the same API as HTTP ? what happen with external packages? will the API change? > I don't like the current API at all and I'm glad Zinc is different. But for legacy purposes a facade should be easy to implement that resembles the existing one. On the long run some of the calls should vanish and only the httpGet: and friends should survive to offer a really really easy and basic access to http. my 2 cents, Norbert > Cheers > > Mariano > > On Sat, Apr 16, 2011 at 3:13 PM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > I would like to know exactly what features will provide Zn and which not. > > As I remember form the past was not planned to support for example > https, which prevent to use OAuth and OpenID, very needed to develop > any interaction against any modern web site. > > Cheers. > GermÃ¡n. > > > 2011/4/16 Norbert Hartl <norbert(a)hartl.name>: > > > > Am 15.04.2011 um 22:12 schrieb StÃ©phane Ducasse: > > > >> Hi guys > >> > >> we discuss with sven about strategies to get a better infrastructure and the HTTP level. > >> Sven would like to have feedback on Zinc before pushing it in Pharo :) > >> So can you let us know. What we could do it to have it in a preview in 1.3 > >> then in 1.4 remove HTTPClient (or friend). > > > > This is really good. To me (meaning IMHO) it is one of the most missing functionalities in pharo. Zinc is really great and so much better than _anything_ in pharo that pretends to do HTTP. I would like to see it that we don't talk about HTTP but about proper MIME based communication. I think the very core that is in there is the structured and flexible mime media handling and communication. And this is not only true for HTTP but also for email. > > I would like to see that Zinc creeping into the image bringing the mime stuff along. Than the mime stuff should break loose of the Zinc components and should replace the mime handling that is in the image. Than we have it for http and for mail sending and for every other transport protocol you can imagine. > > And now that Paul ported zinc to gemstone you can develop good http handlers that are easily ported to gemstone. What a wonderful world! > > And seaside? Well, if the current http adaptors are much faster than zinc than there should be shortcut path through zinc that allows fast handling of the minimal stuff seaside needs. The same problem goes for the WARequest stuff. Using zinc you can get access to the mime parts. Now WARequest is a strange request object that contains a dictionary for request parameters and a raw message body. If only compatibility is important than a zinc to old WARequest handling is needed. But I would like to see the mime based handling to be the "normal" way of doing and not vice versa. But I can see that it must be a special treatment as seaside is ported to so many platforms that don't have zinc. Probably one reasone more to extract the mime stuff. It might be a promininent candidate other platforms adopt. > > > > my two cents, > > > > Norbert > > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

April 16, 2011