- Pharo-users - lists.pharo.org

Re: [Pharo-users] Xcode's Swift Playground

by stepharo

Nicolas Passerini and Pablo Tesone are working on a type inferencer for Pharo and this is exciting :) On 3/6/14 17:59, Johan Fabry wrote: > On Jun 3, 2014, at 4:57 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> We have to do some type inference (for tools) some time. Should be fun. (by the way, is there something like that already?) > There has been some work done on type inference for Smalltalk, the RoelTyper example that I keep mentioning worked on Squeak and there was a version on VW that Roel and I looked at in Gent a couple of years ago, but we did not go that way. More recently there was a google summer of code project on concrete type inference for Pharo if I am not mistaken. > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

June 4, 2014

Re: [Pharo-users] Accessing DLLs in Smalltalk/V

by Markus Fritsche

On 30.05.2014 08:50, Joachim Geidel wrote: > Yes, this page helped, but as you wrote: basic and simple example - > the more involved stuff remains undocumented. When working on JNIPort, > I struggled with simple things like de-referencing a pointer to a > pointer to a struct etc. - I didnât find documentation for this, and > this is a basic feature in my opinion. Looking through blog posts and the mailing list archive, I didn't find it so hard to work with (yet), but I am also just dealing with opaque types. One thing I'd wish to learn more about is proper resource management - the library I am using is constructing a tree of connected structs, and I haven't found a recipe how to deal with that (integrating with the pharo vm garbage collector). <thread_hijack>Silly question: where can I find information about finalization et al in Pharo/ Squeak? My google searches didn't yield any results that where easy to understand.</thread_hijack>

June 3, 2014

MorphTree behavior changed

by Hilaire Fernandes

Hi, why when morph tree send updateList there is an announcement from the model? It was not the case before. Thanks Hilaire -- Dr. Geo http://drgeo.eu

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Johan Fabry

On Jun 3, 2014, at 12:32 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 3 juin 2014, at 17:34, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > >> >> On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>>> To what I understand, types are inferred, it is not statically typed. Am I wrong ? >>> >>> If there is type inference then it is statically typed (at least partially if not every variable type can be inferred) >> >> To repeat myself: this is not the case. Example is the RoelTyper. > > Yes, there are many type inferencers for dynamically-typed languages. > But that's not because one builds a type inferencer for say Smalltalk that I can say "Smalltalk has type inference": the inferencer is not integrated within the language, it's just an analysis tool on top. > If someone says that his language has type inference, he means that the type inferencer is built into the language, and normally there is some type checking and/or the compiler is designed to leverage type information which means that the language is at least partially statically-typed (if not entirely). I tend to disagree: in the case of Smalltalk the border between the language and the toolchain is quite blurry. Is the browser part of the language? Refactoring support? Type inferencer? Where do you draw the line? I can have my Smalltalk dialect with type inferencing while the language is dynamically typed. And that does not take into account all the fancy type stuff such as gradual typing, like in Gradualtalk, optional typing like Pegon (if Iâm not mistaken). > Because if a language does no type checking nor type-based optimisations, for what purpose would it have type inference built into it? Documentation. Static types are a good form of documentation, when done right. :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Camille Teruel

On 3 juin 2014, at 17:34, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >>> To what I understand, types are inferred, it is not statically typed. Am I wrong ? >> >> If there is type inference then it is statically typed (at least partially if not every variable type can be inferred) > > To repeat myself: this is not the case. Example is the RoelTyper. Yes, there are many type inferencers for dynamically-typed languages. But that's not because one builds a type inferencer for say Smalltalk that I can say "Smalltalk has type inference": the inferencer is not integrated within the language, it's just an analysis tool on top. If someone says that his language has type inference, he means that the type inferencer is built into the language, and normally there is some type checking and/or the compiler is designed to leverage type information which means that the language is at least partially statically-typed (if not entirely). Because if a language does no type checking nor type-based optimisations, for what purpose would it have type inference built into it? > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

June 3, 2014

Re: [Pharo-users] PIllar >> #visitAnnotatedParagraph:

by Ben Coman

Damien Cassou wrote: > On Sun, Jun 1, 2014 at 6:10 PM, Ben Coman<btc(a)openinworld.com> wrote: >> Yes. I am doing something similar. btw, is it a strong convention that Tex commands and environments are all lowercase? That is, should I force the annotation label in "\begin{note}" to lowercase, or should I pass that through unchanged. > > > I think you should not change anything. Is it up to the writer to do > something not stupid. > >>> For Markdown, we should probably have the same solution as for HTML. >> I had a hunt around and it seems that Markdown doesn't support paragraph styles. And the workaround specified here... >> http://stackoverflow.com/questions/1058933/can-i-define-a-class-name-on-par… >> >> apparently does not work on github... >> https://github.com/github/markup > > in pillar we have both Markdown and GithubMarkdown as export options. > So we can have a solution dedicated to github if required. > > >> But Hey! Check this out... >> https://github.com/github/markup/blob/master/CONTRIBUTING.md >> >> Maybe we could add a Pillar-->HTML processor to Github? > > > There should not be any technical problem to do that. Do you want to > try? I can help if you have problems. > > >> "If your markup is in a language other than Ruby, drop a translator script in lib/github/commands which accepts input on STDIN and returns HTML on STDOUT..." >> https://github.com/github/markup/blob/master/lib/github/markups.rb >> >> >> So it seems that Text and Markdown cannot produce different formatted paragraphs. > > for text it is clear. For Markdown I'm still not sure if it is > possible or not. Maybe a<div class=<annotation>> would work. > > >> In those two cases, I still lean towards putting the annotation label in the output, but I'm happy enough to leave it out. > > > for text I think we should not change the current export. For > Markdown, I leave the decision to you. > > I've uploaded the updates to make annotations more consistent, and added the \dothis LaTeX command being used in the PharoLaserGame tutorial. source annotation test # item 1 @@note anno1 @@dothis anno2 ## item 11 @@note anno3 ## item 12 @@dothis anno4 ## item 13 --to=pillar annotation test # item 1 @@note anno1 @@dothis anno2 # ## item 11 @@note anno3 # ## item 12 @@dothis anno4 # ## item 13 Now this output is not the same and the source. Should I try to fix this the same as I did for comments. --to=html <div class="container"> annotation test <ol><li> item 1 </li></ol> anno1 anno2 <ol><li> <ol><li> item 11 </li></ol> </li></ol> anno3 <ol><li> <ol><li> item 12 </li></ol> </li></ol> anno4 <ol><li> <ol><li> item 13 </li></ol></li></ol> </div> --to=markdown annotation test 1. item 1 ^M ^M anno1^M ^M anno2^M ^M 1. 1. item 11 ^M ^M anno3^M ^M 1. 1. item 12 ^M ^M anno4^M ^M 1. 1. item 13 btw, what are all these non-break-spaces "^M ^M" for? --to=markdown \begin{document}^M^M annotation test \begin{enumerate} \item item 1 \end{enumerate} \begin{note} anno1 \end{note} \dothis{ anno2 }\begin{enumerate} \item \begin{enumerate} \item item 11 \end{enumerate} \end{enumerate} \begin{note} anno3 \end{note} \begin{enumerate} \item \begin{enumerate} \item item 12 \end{enumerate} \end{enumerate} \dothis{ anno4 }\begin{enumerate} \item \begin{enumerate} \item item 13 \end{enumerate} \end{enumerate} ^M^M\end{document}^M --to=text annotation test 1. item 1 anno1 anno2 1. 1. item 11 anno3 1. 1. item 12 anno4 1. 1. item 13 cheers -ben

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Johan Fabry

On Jun 3, 2014, at 4:57 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > We have to do some type inference (for tools) some time. Should be fun. (by the way, is there something like that already?) There has been some work done on type inference for Smalltalk, the RoelTyper example that I keep mentioning worked on Squeak and there was a version on VW that Roel and I looked at in Gent a couple of years ago, but we did not go that way. More recently there was a google summer of code project on concrete type inference for Pharo if I am not mistaken. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Johan Fabry

On Jun 3, 2014, at 4:21 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> To what I understand, types are inferred, it is not statically typed. Am I wrong ? > > If there is type inference then it is statically typed (at least partially if not every variable type can be inferred) To repeat myself: this is not the case. Example is the RoelTyper. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 3, 2014

Re: [Pharo-users] Xcode's Swift Playground

by Johan Fabry

On Jun 3, 2014, at 3:10 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> What's interesting about swift is not only that Apple chose an existing name for their new programming language (interesting for a company that is very careful about their own brand names), but that swift seems to be statically typed, while one of the biggest advantages of Objective-C is that it allows for dynamic typing (to some extent)... > > To what I understand, types are inferred, it is not statically typed. Am I wrong ? Type inference is actually orthogonal to static or dynamic typing. You can have a statically typed language with inferred types, where the programmer needs to put type annotations on places where the type inferrer gets lost, and you can infer types for a dynamically typed language. An example of the latter would be the RoelTyper shown at ESUG a looong time ago ;-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

June 3, 2014

Re: [Pharo-users] Curl markup with Pillar

by Damien Cassou

On Tue, Apr 22, 2014 at 3:30 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > The links in there do not seem to work. When linking to smalltalkhub the ~is exchanged by %7E I checked and this is not a bug of Pillar but a bug of github's markdown: https://github.com/github/markup/issues/311 -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 3, 2014