November 2013 - Pharo-users

Thread safe queue like collection

by Esteban A. Maringolo

Hi, Do Pharo 2 have some sort of queue like collection, where different threads (coming mostly from a Multithread Zinc Server) can push objects into it safely, while a service on the other end can consume the queue? Regards, Esteban A. Maringolo

Nov. 13, 2013

Re: [Pharo-users] PetitParser and external streams

by Sean P. DeNigris

Norbert Hartl wrote > Producing the output immediately often has the drawback that it is hard to > alter the stream in between... I've had success outputting-as-I-go in the ==> block, instead of, or in addition to returning the token... ----- Cheers, Sean -- View this message in context: http://forum.world.st/PetitParser-and-external-streams-tp4721440p4721814.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 13, 2013

Re: [Pharo-users] Message naming

by kilon alios

What I tried to say here was that it was a mistake to blame the language itself for code design. Sure a language may have some ugly sides to it, it may even make it not so easy to create clean code but in the end of the day clean and readable code is up to the coder at least 90% . I would not say that there are subtle differences between Python and Java , Ruby and Scala just by themselves. The differences are quite big actually. My point was that good design is something that many if not most languages promote. Why ? Because nobody likes ugly code. Actually most java developers hate long names for methods, there is even a quora question on the subject that many Java coders express their frustration on the subject. For example your naming issues is pretty much the foundation of design of Python's Standard Library , one of the most respected included libraries in the programming world. This is the zen of python : Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! As you can see obviously from this Zen , long names and monolithic approaches are out of the door. So if you think that python would motivate you to use long names for methods , then you are easily mistaken and you better ask some python coders what they think a "pythonic" code really looks like. You will be suprized how much common ground you will find with Pharo people. I am willing to bet Ruby folks will be even more inclined to follow smalltalk values since their language was largely based on smalltalk. Ignacio, I think its a great idea to have a Zen as a community. In the python world its started as a joke, then it was viewed as a serious joke, currently is viewed as something so serious, that if a library does not follow it its regarded as "unpythonic" and believe me no python coder wants his code to be called unpythonic. So even though the zen is not very specific I think it clearly shows the direction of what python community considers as good code. Should Pharo have something similar ? its certainly should have. I think its important to have values, to aspire to create better designed code, to not repeat the mistakes of the past or mistakes of others, to pass knowledge and experience around. The trend for modern coding is to move closer to this area, smaller libraries are in favor instead of large libs, documentation plays a much more important role, OO mixed with other paradigms like functional programming etc gives even more freedom of choice, the rule of least surprise is followed more and more. Where some see smalltalk as a dead or niche language, I see it being used everywhere and by everyone to lesser or bigger degree. This is is our future. On Wed, Nov 13, 2013 at 5:29 PM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > Kilon, I believe there's a subtle difference between Python, Java, Ruby > and Scala on one side and Smalltalk on the other: > All those 4 languages are more or less implemented as OO languages with > the famous statement "everything is an object". However they are > syntactically and semantically designed in a way that they allow a not OO > design to be coded. Just imagine the small problem I shared in this > thread; in any of those languages I can do it with one class and a couple > of static methods and the code will definitely *read and work naturally > correct*. > > On the other hand, consider Smalltalk: "everything is an object", but the > syntax and semantics of the language is different. Yes, it allows a not OO > design to be coded but there's a difference: think about my small problem > again. The moment I thought about coding it the old style (single class > with static methods) something started to smell. It smelled so bad that I > had to consult you folks. > > That's what I'm talking about: a tiny but subtle and well thought out > difference in the syntax and semantics and it makes a huge difference. > > Another example: > I -like all of you- had studied, heard, read and practiced bottom-to-top > design and I thought I knew what it meant. However, the moment I started > coding in Lisp I found out I knew little about that paradigm. The natural > subtle semantic design of Lisp made it a natural bottom-to-top platform > nothing like any other platform I had seen until then. > > > > On 11/13/2013 18:27, kilon alios wrote: > > I dont know exactly what you mean by eforced OOP by design. Pharo design > principles are not written in stone, just good habits people picked along > the way and they are to be found in python as well. Python actually takes > OO very deply , sure if , else, while are language constructs but rest > assured that everything else is an object. For example unlike Pharo , > python allows to do procedural programming , but python functions are > objects in disguise . You could say that python functions work similarly > (but not the same , since closures are not supported in python) to Pharo > blocks. > > Ruby is even closer to Pharo, supporting blocks, message passing etc. > Also those kind of languages take clean design in code, very seriously. > Just go to python interpreter console and do "import this" and you will see > the zen of python unfold before your eyes emphasizing the good design > principles you will find many smalltalkers talking about. Another language > taking these principles very seriously is Lisp, actually Smalltalk took a > lot from lisp in terms of overall design and direction. > > Of course clean code in the end is a choice , there is no enforcement, > you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There > is no capital punishment for coders that don't follow these principles. > Many coders care only for getting the job done and feel like they dont have > time to worry about how clean their code is. Its a free world, or so we > hope. > > On the other hand everything should be put into context and never taken > as the Holy Bible or Holy Grail. > > > On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com>wrote: > >> @Sven >> > There is not necessarily a right and a wrong way. Design is hard to >> > explain, I am not going to try. Sorry ;-) >> >> Of course! I was just trying to find out the design *norm* for a small >> problem; to become familiar with the popular way of thought among >> Smalltalk'ers. >> >> @kilon >> Thanks. I think that may be what I need: real world examples. >> >> As I have already admitted, I am not used to Smalltalk way of thinking. >> This is the first language I know, that enforces OOP by design, none of >> Java, Python, C++ or Scala does. It's ironic; OOP concepts and >> techniques were among the first things I was taught back in University >> but now the more I think about Smalltalk's syntax and design, the more I >> get closer to the conclusion that I didn't use pure OOP many times >> during my career. And, I believe, it was simply because the development >> platforms never enforced it the way Smalltalk does: in a clever and >> camouflaged way. >> >> > But please do have a look at the Chronos library, it even has a >> PersianCalender, among many others. >> >> I knew about Chronos. Someone here, kindly suggested it about 6 months >> ago when I asked about such a thing. I'm not trying to re-write >> something like Chronos rather I'm trying to get my hands dirty with >> Pharo and also re-visit my OOP skills. Thanks. >> >> > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 13, 2013

Re: [Pharo-users] Add menu item to Nautilus context menu on selected packages?

by Benjamin

You can give them a priority, then it depends of the other items :) Ben On 13 Nov 2013, at 17:31, MartinW <wm(a)fastmail.fm> wrote: > Quite easy indeed. Thank you. > Is there any system behing the ordering of menu entries? > > Martin. > > > Benjamin Van Ryseghem-2 wrote >> It is :) >> And I would even say it is not complicated :P >> >>> So far i added a wizard to the world menu, but i would rather add a menu >>> item to the Nautilus context menu on selected packages - is this >>> possible? > > > > > > -- > View this message in context: http://forum.world.st/Add-menu-item-to-Nautilus-context-menu-on-selected-pa… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Nov. 13, 2013

Re: [Pharo-users] Add menu item to Nautilus context menu on selected packages?

by MartinW

Quite easy indeed. Thank you. Is there any system behing the ordering of menu entries? Martin. Benjamin Van Ryseghem-2 wrote > It is :) > And I would even say it is not complicated :P > >> So far i added a wizard to the world menu, but i would rather add a menu >> item to the Nautilus context menu on selected packages - is this >> possible? -- View this message in context: http://forum.world.st/Add-menu-item-to-Nautilus-context-menu-on-selected-pa… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Ignacio MatÃas Sniechowski

Kilon, great reflection. We should have Pharo display Pharo Zen as exposed in Pharo Vision: Pharo Zen Our values and convictions are condensed in this simple list. Easy to understand, easy to learn from, easy to change. Objects all the way down. Examples to learn from. Fully dynamic and malleable. Beauty in the code, beauty in the comments. Simplicity is the ultimate elegance. Better a set of small polymorphic classes than a large ugly one. Classes structure our vocabulary. Messages are our vocabulary. Polymorphism is our esperanto. Abstraction and composition are our friends. Tests are important but can be changed. Explicit is better than implicit. Magic only at the right place. One step at a time. There is no unimportant fix. Learning from mistakes. Perfection can kill movement. Quality is a emerging property. Simple processes to support progress. Communication is key. A system with robust abstractions that a single person can understand. :D best nacho *Lic. Ignacio Sniechowski, MBA* On Wed, Nov 13, 2013 at 11:57 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > I dont know exactly what you mean by eforced OOP by design. Pharo design > principles are not written in stone, just good habits people picked along > the way and they are to be found in python as well. Python actually takes > OO very deply , sure if , else, while are language constructs but rest > assured that everything else is an object. For example unlike Pharo , > python allows to do procedural programming , but python functions are > objects in disguise . You could say that python functions work similarly > (but not the same , since closures are not supported in python) to Pharo > blocks. > > Ruby is even closer to Pharo, supporting blocks, message passing etc. Also > those kind of languages take clean design in code, very seriously. Just go > to python interpreter console and do "import this" and you will see the zen > of python unfold before your eyes emphasizing the good design principles > you will find many smalltalkers talking about. Another language taking > these principles very seriously is Lisp, actually Smalltalk took a lot from > lisp in terms of overall design and direction. > > Of course clean code in the end is a choice , there is no enforcement, you > will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no > capital punishment for coders that don't follow these principles. Many > coders care only for getting the job done and feel like they dont have time > to worry about how clean their code is. Its a free world, or so we hope. > > On the other hand everything should be put into context and never taken as > the Holy Bible or Holy Grail. > > > On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com>wrote: > >> @Sven >> > There is not necessarily a right and a wrong way. Design is hard to >> > explain, I am not going to try. Sorry ;-) >> >> Of course! I was just trying to find out the design *norm* for a small >> problem; to become familiar with the popular way of thought among >> Smalltalk'ers. >> >> @kilon >> Thanks. I think that may be what I need: real world examples. >> >> As I have already admitted, I am not used to Smalltalk way of thinking. >> This is the first language I know, that enforces OOP by design, none of >> Java, Python, C++ or Scala does. It's ironic; OOP concepts and >> techniques were among the first things I was taught back in University >> but now the more I think about Smalltalk's syntax and design, the more I >> get closer to the conclusion that I didn't use pure OOP many times >> during my career. And, I believe, it was simply because the development >> platforms never enforced it the way Smalltalk does: in a clever and >> camouflaged way. >> >> > But please do have a look at the Chronos library, it even has a >> PersianCalender, among many others. >> >> I knew about Chronos. Someone here, kindly suggested it about 6 months >> ago when I asked about such a thing. I'm not trying to re-write >> something like Chronos rather I'm trying to get my hands dirty with >> Pharo and also re-visit my OOP skills. Thanks. >> >> -- >> Bahman Movaqar (http://BahmanM.com) >> >> ERP Evaluation, Implementation & Deployment Consultant >> PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) >> >> >> >> >> >

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Bahman Movaqar

Kilon, I believe there's a subtle difference between Python, Java, Ruby and Scala on one side and Smalltalk on the other: All those 4 languages are more or less implemented as OO languages with the famous statement "everything is an object". However they are syntactically and semantically designed in a way that they allow a not OO design to be coded. Just imagine the small problem I shared in this thread; in any of those languages I can do it with one class and a couple of static methods and the code will definitely *read and work naturally correct*. On the other hand, consider Smalltalk: "everything is an object", but the syntax and semantics of the language is different. Yes, it allows a not OO design to be coded but there's a difference: think about my small problem again. The moment I thought about coding it the old style (single class with static methods) something started to smell. It smelled so bad that I had to consult you folks. That's what I'm talking about: a tiny but subtle and well thought out difference in the syntax and semantics and it makes a huge difference. Another example: I -like all of you- had studied, heard, read and practiced bottom-to-top design and I thought I knew what it meant. However, the moment I started coding in Lisp I found out I knew little about that paradigm. The natural subtle semantic design of Lisp made it a natural bottom-to-top platform nothing like any other platform I had seen until then. On 11/13/2013 18:27, kilon alios wrote: > I dont know exactly what you mean by eforced OOP by design. Pharo > design principles are not written in stone, just good habits people > picked along the way and they are to be found in python as well. > Python actually takes OO very deply , sure if , else, while are > language constructs but rest assured that everything else is an > object. For example unlike Pharo , python allows to do procedural > programming , but python functions are objects in disguise . You could > say that python functions work similarly (but not the same , since > closures are not supported in python) to Pharo blocks. > > Ruby is even closer to Pharo, supporting blocks, message passing etc. > Also those kind of languages take clean design in code, very > seriously. Just go to python interpreter console and do "import this" > and you will see the zen of python unfold before your eyes emphasizing > the good design principles you will find many smalltalkers talking > about. Another language taking these principles very seriously is > Lisp, actually Smalltalk took a lot from lisp in terms of overall > design and direction. > > Of course clean code in the end is a choice , there is no enforcement, > you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . > There is no capital punishment for coders that don't follow these > principles. Many coders care only for getting the job done and feel > like they dont have time to worry about how clean their code is. Its a > free world, or so we hope. > > On the other hand everything should be put into context and never > taken as the Holy Bible or Holy Grail. > > > On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com > <mailto:Bahman@bahmanm.com>> wrote: > > @Sven > > There is not necessarily a right and a wrong way. Design is hard to > > explain, I am not going to try. Sorry ;-) > > Of course! I was just trying to find out the design *norm* for a > small > problem; to become familiar with the popular way of thought among > Smalltalk'ers. > > @kilon > Thanks. I think that may be what I need: real world examples. > > As I have already admitted, I am not used to Smalltalk way of > thinking. > This is the first language I know, that enforces OOP by design, > none of > Java, Python, C++ or Scala does. It's ironic; OOP concepts and > techniques were among the first things I was taught back in University > but now the more I think about Smalltalk's syntax and design, the > more I > get closer to the conclusion that I didn't use pure OOP many times > during my career. And, I believe, it was simply because the > development > platforms never enforced it the way Smalltalk does: in a clever and > camouflaged way. > > > But please do have a look at the Chronos library, it even has a > PersianCalender, among many others. > > I knew about Chronos. Someone here, kindly suggested it about 6 > months > ago when I asked about such a thing. I'm not trying to re-write > something like Chronos rather I'm trying to get my hands dirty with > Pharo and also re-visit my OOP skills. Thanks. > -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 13, 2013

Re: [Pharo-users] PetitParser and external streams

by Norbert Hartl

Am 13.11.2013 um 13:15 schrieb Federico.Balaguer <federico.balaguer(a)gmail.com>: > Thanks Norbert for your kind reply. > > My only reminding question is about the input. PetitStream are made from the > contents of another stream. So, if I have a readStream on a file and I > convert it to PetitStream, it will end up loading the entire content of the > file on memory. > > Could it be possible to use a "LazyPetitStream" that is getting the content > from the original stream incrementally? > I donât think so. What I said in my last mail is valid for the input stream as well. Parsing is about trying to match some content in multiple ways. This implies that you need to check if something matches and if it fails try matching something else. That also means you need to backtrack or better you need to get back and forth within a stream. This makes streaming less an option because youâll always need to buffer and the buffer is likely to be as big as the whole content. I donât know what you are trying to achieve but probably there is another solution. Your mail sounds as you are concerned about memory consumption. Assuming further it is probably not a single entity you try to parse but a list of the same entity. In the case you could leave out the outermost star or plus parser and use the parser for a single entity until the end of the stream. So you would use the parser multiple times producing smaller chunks in memory. Hope this helps, Norbert

Nov. 13, 2013

Re: [Pharo-users] Message naming

by kilon alios

I dont know exactly what you mean by eforced OOP by design. Pharo design principles are not written in stone, just good habits people picked along the way and they are to be found in python as well. Python actually takes OO very deply , sure if , else, while are language constructs but rest assured that everything else is an object. For example unlike Pharo , python allows to do procedural programming , but python functions are objects in disguise . You could say that python functions work similarly (but not the same , since closures are not supported in python) to Pharo blocks. Ruby is even closer to Pharo, supporting blocks, message passing etc. Also those kind of languages take clean design in code, very seriously. Just go to python interpreter console and do "import this" and you will see the zen of python unfold before your eyes emphasizing the good design principles you will find many smalltalkers talking about. Another language taking these principles very seriously is Lisp, actually Smalltalk took a lot from lisp in terms of overall design and direction. Of course clean code in the end is a choice , there is no enforcement, you will find plenty of ugly code in Pharo, Python, Ruby and Lisp . There is no capital punishment for coders that don't follow these principles. Many coders care only for getting the job done and feel like they dont have time to worry about how clean their code is. Its a free world, or so we hope. On the other hand everything should be put into context and never taken as the Holy Bible or Holy Grail. On Wed, Nov 13, 2013 at 4:37 PM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > @Sven > > There is not necessarily a right and a wrong way. Design is hard to > > explain, I am not going to try. Sorry ;-) > > Of course! I was just trying to find out the design *norm* for a small > problem; to become familiar with the popular way of thought among > Smalltalk'ers. > > @kilon > Thanks. I think that may be what I need: real world examples. > > As I have already admitted, I am not used to Smalltalk way of thinking. > This is the first language I know, that enforces OOP by design, none of > Java, Python, C++ or Scala does. It's ironic; OOP concepts and > techniques were among the first things I was taught back in University > but now the more I think about Smalltalk's syntax and design, the more I > get closer to the conclusion that I didn't use pure OOP many times > during my career. And, I believe, it was simply because the development > platforms never enforced it the way Smalltalk does: in a clever and > camouflaged way. > > > But please do have a look at the Chronos library, it even has a > PersianCalender, among many others. > > I knew about Chronos. Someone here, kindly suggested it about 6 months > ago when I asked about such a thing. I'm not trying to re-write > something like Chronos rather I'm trying to get my hands dirty with > Pharo and also re-visit my OOP skills. Thanks. > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > > > > >

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Bahman Movaqar

@Sven > There is not necessarily a right and a wrong way. Design is hard to > explain, I am not going to try. Sorry ;-) Of course! I was just trying to find out the design *norm* for a small problem; to become familiar with the popular way of thought among Smalltalk'ers. @kilon Thanks. I think that may be what I need: real world examples. As I have already admitted, I am not used to Smalltalk way of thinking. This is the first language I know, that enforces OOP by design, none of Java, Python, C++ or Scala does. It's ironic; OOP concepts and techniques were among the first things I was taught back in University but now the more I think about Smalltalk's syntax and design, the more I get closer to the conclusion that I didn't use pure OOP many times during my career. And, I believe, it was simply because the development platforms never enforced it the way Smalltalk does: in a clever and camouflaged way. > But please do have a look at the Chronos library, it even has a PersianCalender, among many others. I knew about Chronos. Someone here, kindly suggested it about 6 months ago when I asked about such a thing. I'm not trying to re-write something like Chronos rather I'm trying to get my hands dirty with Pharo and also re-visit my OOP skills. Thanks. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 13, 2013