November 2013 - Pharo-users

Re: [Pharo-users] A question concerning fonts

by Sven Van Caekenberghe

Hi Mateusz, On 13 Nov 2013, at 20:17, Mateusz Grotek <unoduetre(a)poczta.onet.pl> wrote: > Hi, > Is it possible to use nonascii/nonenglish characters in a workspace and > browser. I have changed the font, but I still get question marks... > > Pharo1.3 > Latest update: #13327 > > Seaside 3.07 One-Click image from here: > http://www.seaside.st/distributions/Seaside-3.0.7-OneClick.zip > > Mateusz Grotek You can try enabling FreeType fonts and selecting a font that can display more characters, like Arial Unicode MS. HTH, Sven

Nov. 13, 2013

Re: [Pharo-users] Thread safe queue like collection

by Sven Van Caekenberghe

Yes, I have used it, even extended it. It looks thread safe, so it should be enough to get started. On 13 Nov 2013, at 20:08, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I guess SharedQueue will do it, have you (or anybody) tested it in the context of real multi threaded use? > > It is too soon for me to think of a real MQ (with STOMP). > > Regards! > > Esteban A. Maringolo > > > 2013/11/13 Sven Van Caekenberghe <sven(a)stfx.eu> > SharedQueue ? > > On 13 Nov 2013, at 19:16, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > > 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

A question concerning fonts

by Mateusz Grotek

Hi, Is it possible to use nonascii/nonenglish characters in a workspace and browser. I have changed the font, but I still get question marks... Pharo1.3 Latest update: #13327 Seaside 3.07 One-Click image from here: http://www.seaside.st/distributions/Seaside-3.0.7-OneClick.zip Mateusz Grotek

Nov. 13, 2013

Re: [Pharo-users] Thread safe queue like collection

by Esteban A. Maringolo

I guess SharedQueue will do it, have you (or anybody) tested it in the context of real multi threaded use? It is too soon for me to think of a real MQ (with STOMP). Regards! Esteban A. Maringolo 2013/11/13 Sven Van Caekenberghe <sven(a)stfx.eu> > SharedQueue ? > > On 13 Nov 2013, at 19:16, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > 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] Thread safe queue like collection

by Sven Van Caekenberghe

SharedQueue ? On 13 Nov 2013, at 19:16, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 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

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

Re: [Pharo-users] CogVM arguments in Win32

by Igor Stasenko

On 13 November 2013 12:02, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>wrote: > Thanks a lot Torsten! > > I'll invest the whole morning tomorrow in trying to get a little bit more > of this to work. > > If I don't succeed... there are lots of very good restaurants in > Barcelona, Igor ;) > > i can imagine :) I hope i will be able come there once more one day. Barcelona is very beautiful city. :) > 2013/11/13 Torsten Bergmann <astares(a)gmx.de> > >> Hi Bernat, >> >> >how do I translate this into NB code >> >> Either invite Igor (author of NB) for lunch or try this: >> >> >> Its a C-structure, you convert it by wrapping this in a sublcass >> of "NBExternalStructure". See the examples already in a Pharo 3.0 image. >> >> Basically you need: >> >> - define a subclass NBExternalStructure subclass: #WinNotifyIconData ... >> - define the correct fields in a class side #fieldsDesc method according >> to the native data types used in the structure >> - call "WinNotifyIconData rebuildFieldAccessors" >> - setup the types in a shared pool that you can include later: >> >> - define the pool: SharedPool subclass: #WinTryIconConstants ... >> - in a class initialize method you can setup the type >> >> initialize >> >> NOTIFYICONDATA := #WinNotifyIconData. >> PNOTIFYICONDATA:= 'NOTIFYICONDATA *'. >> >> - by including the pool you can use "NOTIFYICONDATA" or "PNOTIFYICONDATA" >> in any native boost call. >> >> >> If you are in Pharo 3.0 load "OS-Windows" package from the config browser. >> Check the subclasses of NBExternalStructure there. >> >> I wrapped many other windows structures already so you can get an idea >> about >> it. For instance have a look at WinConsoleConstants>>initTypeConstants, >> there you will find >> the CONSOLE_CURSOR_INFO, CONSOLE_SCREEN_BUFFER_INFO structs wrapped in >> WinConsoleCursor, WinConsoleScreenBuffer classes. >> >> Compare them with the MSDN struct description. >> >> >Could the Windows API be any more convoluted and dev-unfriendly in any >> >possible sense? >> >> This question should go to M$ not Pharo-user ;) >> >> Bye >> T. >> >> >> BTW: I'm not sure "PNOTIFYICONDATA" alone will solve your problem if I >> remember correctly >> from my Smalltalk/MT and C/C++ times also playing with tray icons. >> I guess you need a callback that gets called when the icon is >> clicked or the tray icon menu >> is choosen (see uCallbackMessage member in the struct). >> You also need a handle to an icon - either the icon from the EXEs >> resource section or >> by loading one from a bitmap. That means wrapping the icon or bitmap >> apis too... >> >> > > > -- > Bernat Romagosa. > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Igor Stasenko

On 13 November 2013 11:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > JB can you read and reply to this mail? > > Hi > > What Doru wrote pretty much sums it up. > > CodeCity under VW was based on JUN, which provided a programmer-friendly > API built on top of OpenGL. Since there is no such thing under Pharo, when > I later started to work on CodeCity under Pharo, I needed to learn about > how to program directly to OpenGL. And the only example I had for that was > SourceCity. In the meantime I manage to get a grip on my basic needs and > was ready to move forward to implementing CodeCity. Now that does not work > anymore in Pharo 3.0 so I am stuck. I could continue to program under Pharo > 2.0, but what's the point? > > > for now probably, because if you that is the one the most interested guy > in that does not have the time to understand why others that > do not need 3D should do it. NBOpenGL was a side project to give a try of > busy people too. I'm sorry to say that > but we cannot be on all fronts especially when they are changing. > > So can you tell us if you see what changed between 2 and 3. I have no idea. > > NBOpenGL needs to be updated to sync with changes in NB about NBExternalStructure. Right now it cannot even be loaded into 3.0. But update is simple (i think JB did that already, just not published?). > I have already looked at Roassal 3d, but it was not easy to separate the > API from the code. > > > Strange because even me I could see that the shadder code should not be in > Roassal 3D but in NBOpenGL :). > Because Roassal 3d should not be about shadder but about 3D. > > And it is something completely different than what I have been using (and > SourceCity, too), because Roassal 3d is using the modern OpenGL methodology > (with FBOs and stuff). > > > Yes they changed the API and deprecated the old way of doing it. > > So, I would really appreciate if that API would find its way from Roassal > to NBOpenGL and I could use it for CodeCity. > > > See below > > Unfortunately I am able to help a lot with that, because I know very > little about this and I also don't have enough time (I am doing CodeCity in > my spare time). But, if you have concrete things that I can do, I'd be > happy to help. > > > Three remarks: > - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL > - I'm not sure that doing 3d without investing a bit in the underlying > technology is wise. Because you will be always relying > on other people and probably frustrated when things are not working. > - Since JB does not know how to communicate here is what he did for fun > instead of pushing MoosePython :) > a renderer to video to videos stream for openGL -> MKV, mp4 based one > ffmpeg). The code is openGL extra. As an example you > can get > https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk > > Now again if nobody builds a jun like library in Pharo it will not exist. > > Stef > > > > Cheers > Ricky > > > > > On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I guess that what Ricky is asking is what changed between NBOpenGL 2.0 >> and 3.0 such that this does not work anymore on Windows. The fact that he >> mentioned 64 bits is not relevant for this discussion :). >> >> I also guess he wants to put some effort into understanding this as well >> but he needs a bit of guidance. Right Ricky? >> >> Cheers, >> Doru >> >> >> >> On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Richard >>> >>> you should have a look at ROASSAL 3d because ronie improved the shadder >>> part (no more assembler) >>> and his code should be split in two and one part should go to NBOpenGL. >>> Now he is experiencing some problem with NBOpenGL on windows as you. >>> >>> NativeBoost does not work on 64 bits. Yet but igor is really busy >>> finishing the texteditor (and I can tell you that >>> he does not have fun there). >>> >>> So it is important that you help because we are FULL >>> and sorry about that but really FULL. >>> >>> Ronie will visit us in January and share an office with igor. >>> >>> Stef >>> >>> >>> > Hi >>> > >>> > CodeCity, the project I am working on is based on NBOpenGL. >>> > I'd like to start working on it using Pharo 3, but it seems that >>> NBOpenGL does not work yet with Pharo 3.0. >>> > >>> > I downloaded from jenkins the latest image with Pharo 3 and tried to >>> execute the following code on Windows 7, 64 bits: >>> > >>> > GLTTRenderingDemo new openInWorld. >>> > >>> > but I get a 'No suitable implementation found for initializing OpenGL >>> context for your platform'. >>> > It seems that NBGLContextDriver does not have a subclass for Windows >>> 64bits. Did I omit something? >>> > >>> > Cheers >>> > Ricky >>> > >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Igor Stasenko

On 13 November 2013 10:25, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>wrote: > Hi list, > > I made some progress but I'm still a bit lost here. > > I managed to get Pharo to be headless in Win32, by hiding the window via > NB as Igor suggested, plus suspending the UI process (UIManager default > uiProcess suspend), which was the cause for the window to show up again > after a fraction of a second, because of the refresh interval. > > However, now I can only close Pharo by killing the process manually, which > is not very nice for the end user. So I figured I'd try to add an icon to > the system tray with a single context menu entry for closing Pharo. > > This is what I'm doing, taken from MSDN<http://msdn.microsoft.com/en-us/library/windows/desktop/bb762159(v=vs.85).a…> > : > > NBWin32Shell >> shellNotifyIcon: lpdata dwMessage: dwMessage > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > > ^ self nbCall: #(bool Shell_NotifyIcon( > > DWORD dwMessage, > > PNOTIFYICONDATA lpdata > > )) module: #shell32 > > dwMessage is just a 0 (flag to create a tray icon), but lpdata needs to be a > pointer to a struct of this form<http://msdn.microsoft.com/en-us/library/windows/desktop/bb773352(v=vs.85).a…> > : > > typedef struct _NOTIFYICONDATA { > DWORD cbSize; > HWND hWnd; > UINT uID; > UINT uFlags; > UINT uCallbackMessage; > HICON hIcon; > TCHAR szTip[64]; > DWORD dwState; > DWORD dwStateMask; > TCHAR szInfo[256]; > union { > UINT uTimeout; > UINT uVersion; > }; > TCHAR szInfoTitle[64]; > DWORD dwInfoFlags; > GUID guidItem; > HICON hBalloonIcon; > } NOTIFYICONDATA, *PNOTIFYICONDATA; > > > So, my question is: how do I translate this into NB code? How does one > define a struct and then pass its pointer to a function in NativeBoost? > > This is easy. Just make a subclass of NBExternalStructure, define its fields in #fieldsDesc method (see example subclass). Create it using #new, or #externalNew depending if structure should be non-moving in memory for the rest of its life (but i think its needed only at the moment of call, so #new should work), fill it with proper values, and then pass it to that function. Just make sure that argument type PNOTIFYICONDATA changed to class name of your structure in function signature. Also, note that there is two Shell_NotifyIcon functions under the hood: Shell_NotifyIconA Shell_NotifyIconW the 'A' stands for 'ascii', and 'W' stands for 'wide', this is how windows manages strings and characters/unicode. For 'A' functions TCHAR == char (1byte) for 'W' functions TCHAR == unsigned short (2bytes) that means the definition and size of PNOTIFYICONDATA is different depending on what function you going to be using. Thanks a lot for your help, I'm getting closer :) > > Bernat. > > p.s. Could the Windows API be any more convoluted and dev-unfriendly in > any possible sense? > hehe.. this is a typical for everything in windows: many, even basic things require passing and filling various structures with many different fields, and you may find that to initialize fields of one structure, you often need to create another one and initialize it first :) > > > 2013/11/4 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > >> Hi! >> >> Thanks Igor, that kinda worked! Pharo hides, but comes back after half a >> second or so. I'll keep digging, thanks! :) >> >> >> 2013/11/1 phil(a)highoctane.be <phil(a)highoctane.be> >> >> Well, this should rather be: >>> >>> handle :=NativeBoostWin32 squeakWindowHandle. >>> window := NBWin32Window new value: handle; yourself. >>> window hide. >>> >>> or >>> >>> window setWindowText: 'im a main window blablabla'. >>> >>> Phil >>> >>> >>> On Thu, Oct 31, 2013 at 10:03 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> You can try something like this: >>>> >>>> | handle window | >>>> >>>> handle := NativeBoost forCurrentPlatform squeakWindowHandle. >>>> window := NBWin32Window new value: handle; yourself. >>>> window hide. >>>> >>>> or >>>> >>>> window setWindowText: 'im a main window blablabla'. >>>> >>>> :) >>>> >>>> i didn't tested it since its been implemented, but i think it should >>>> work. >>>> >>>> >>>> >>>> On 30 October 2013 11:20, Bernat Romagosa < >>>> tibabenfortlapalanca(a)gmail.com> wrote: >>>> >>>>> In this direction, I'm trying to call a function in the shell32.dll >>>>> lib that apparently should let you minimize an app to the system tray, but >>>>> I'm not having much luck... I guess I don't really understand what am I >>>>> exactly doing. >>>>> >>>>> This is what I found in the MSDN<http://msdn.microsoft.com/en-us/library/bb762159%28VS.85%29.aspx> >>>>> : >>>>> >>>>> BOOL Shell_NotifyIcon( >>>>> _In_ DWORD dwMessage, >>>>> _In_ PNOTIFYICONDATA lpdata >>>>> ); >>>>> >>>>> >>>>> So, I tried to translate this into Pharo as: >>>>> >>>>> MyClass >> minimizeToTray: dwMessage data: lpData >>>>> >>>>> <apicall: bool 'Shell_NotifyIcon' (dword PNOTIFYICONDATA) module: >>>>> 'shell32.dll'> >>>>> >>>>> >>>>> But it won't let me save the method, reporting it's expecting an >>>>> argument before PNOTIFYICONDATA. >>>>> >>>>> I realize PNOTIFYICONDATA is not a primitive type, but I just don't >>>>> know how to handle it... :( >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> Bernat Romagosa. >> > > > > -- > Bernat Romagosa. > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] PetitParser and external streams

by Federico.Balaguer

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? Thanks! Federico -- View this message in context: http://forum.world.st/PetitParser-and-external-streams-tp4721440p4721691.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Sven Van Caekenberghe

Hi Bahman, On 13 Nov 2013, at 09:19, Bahman Movaqar <Bahman(a)BahmanM.com> wrote: > On 11/13/2013 11:39, Bahman Movaqar wrote: >> On 11/13/2013 11:13, Bahman Movaqar wrote: >>> Let's say I have a method with signature in a language like Java as below: >>> gregorianDayToJulianDay(year, month, day) >>> >>> What could be a proper naming for this method in Smalltalk? I'm a bit >>> confused as I'm so used to the concept of methods being "verbs" which >>> accept some arguments. >>> >>> I'd appreciate any help/idea. > > After reading Sven's reply, I came up with this design. Is it the > idiomatic way to handle this problem in Smalltalk: > > <pseudo-design> > class JulianConverter: > instance variable: 'day' > > #toGregorian > #toIranian > > class GregorianConverter: > instance variable: 'year month day' > > #toJulian > > class IranianConverter: > instance variable: 'year month day' > > #toJulian > > </pseudo-design> There is not necessarily a right and a wrong way. Design is hard to explain, I am not going to try. Sorry ;-) But please do have a look at the Chronos library, it even has a PersianCalender, among many others. This is the class comment: [Chronos] All code (classes and methods, and all associated documentation,) distributed as part of the Chronos Date/Time library are Â¬Â© Copyright 2005-2006 by Alan L. Lovejoy. All Rights Reserved. Usage is controlled by the Chronos License (which is included in the distribution as the contents of the file {chronos-license.txt}, and is also available from the Chronos web site {http://www.chronos-st.org/License.html}) PersianCalendar Concept: PersianCalendar implements the arithmetical version of the Persian Calendar. There is also an astronomical version of the Persian Calendar, which some authorities claim is the one actually used in Iran, although other authorities claim otherwise. Chronos does not currently provide implementations of any astronomical calendars. The astronomical version of the Persian Calendar will (eventually) be implemented by class named AstronomicalPersianCalendar, whose registration key will be #'Persian-Astronomical'. For any and all discussion of what a 'Calendar' is conceptually, how an instance of a Calendar can and/or should be used, the general implementation requirements for subclasses of Calendar, or the architectural requirements and responsibilities of Calendar instances with respect to the rest of the Chronos Date/Time Library, please refer to the documentation of class Calendar. The remainder of this text discusses the specific nature of the Persian Calendar itself (and its implementation by this class,) and assumes that the reader has already become familiar with all the concepts and terminology documented in class Calendar. The Persian Calendar (as implemented here) is an arithmetical, solar calendar. A solar calendar is one that attempts to match the (average) length of its years to that of mean solar years. Epoch Date The epoch date of the Persian Calendar, 0001-01-01 [Persian], corresponds to 0622-03-22 [Gregorian] and to 0622-03-19 [Julian]. The Julian Date of the epoch of the Persian Calendar is 1,948,320.50 (midnight.) The epoch date of the Persian Calendar is the vernal equinox of the year in which the "hijra" of Mohammed to Medina occurred ("hijra" means "flight from danger.") The era of the Persian Calendar is called "Anno Persico" or "Anno Persarum" (AP)--which is Latin for "In the Year of Persia/the Persians." Time-of-Day Clock Modernly, midnight is both the zero-point of the time-of-day clock and also the initial moment of the day. However, such has not always been the case for all users of the Persian Calendar. {PersianCalendar clock today} {PersianCalendar clock now} Year Numbering Policy The Persian Calendar uses "zeroless ordinal" year numbering. This means that the epoch year is an ordinal number whose value is 1, and the year that immediately precedes the year 1 is the year -1. Leap Year Rule According to Birashk [A. Birashk, "A Comparative Calendar of the Iranian, Muslim Lunar, and Christian Eras for Three Thousand Years," Mazda Publishers (in association with Bibliotheca Persica,) Costa Mesa, CA, 1993], the arithmetical form of the Persian Calendar uses the following rather complicated leap year rules: There is a master cycle of 2820 years, during which 683 years are leap years. Each standard year contains 365 days, and each leap year contains 366 days, so the master 2820-year cycle contains 1,029,983 days [(2820 * 365) + 683 = 1,029,983]. Based on the current mean length of the tropical year and solar day, there are 1,029,983.00118 days in 2820 tropical years. So, were it not for the fact that a) the length of the tropical year and the length of a mean solar day is slowly changing, and b) the length of the tropical year (which is defined by the duration between winter solstices) is not the same as the length of the spring equinoctial year (which is defined by the duration between vernal equinoxes,) it would be fair to say that the Persian arithmetical calendar deviates from the length of a year by only 101.952 minutes in 2820 years. But for those (and other) caveats, the Persian arithmetical calendar would slip from perfect alignment with the tropical year by only one day every 39,829.68 years--which is astounding accuracy, in spite of the caveats. Within each 2820-year cycle, there are 22 subcycles--the first 21 each contain 128 years, and the 22nd (final) subcycle contains 132 years [2820 = 21 * 128 + 132]. Each 128-year subcycle contains one 29-year sub-subcycle (the first,) followed by three 33-year sub-subcycles [128 = 29 + (3 * 33)]. Each 132-year subcycle contains one 29-year sub-subcycle (the first,) followed by two 33-year sub-subcycles, followed by one 37-year sub-subcycle [132 = 29 + (2 * 33) + 37]. A year in a sub-subcycle (whether it contains 29, 33 or 37 years) is a leap year if the ordinal index of the year within the cycle satisfies the following two predicate tests: 1) it's greater than 1, and 2) the remainder after dividing it by 4 is 1 (so the first year in sub-subcyle is never a leap year; the first leap year is the fifth year in the sub-subcycle.) Thus, a 29-year sub-subcycle has 7 leap years, a 33-year sub-subcycle has 8 leap years, and a 37-year sub-subcycle has 9 leap years (Note: the last year of a sub-subcycle is always a leap year, since 29, 33 and 37 all result in a remainder of 1 when divided by 4) [21 * (7 + (3 * 8)) + (7 + (2 * 8) + 9) = 683]. The base year of the 2820 cycle of years is NOT the Persian year zero or 1, however. The base year of the 2820-year cycle of years is the Persian year 475 (which starts on 21 March 1096 [Gregorian] or 15 March 1096 [Julian].) However, to facilitate the use of modular arithmetic, the Chronos implementation uses Persian year 474 as the zeroeth year of the 2820-year cycle. Algorithm of Predicate Function that answers true if a <persianYear> is a leap year (input arg=<persianYear>): 1. If <persianYear> >= 1 then set <cardinalYear> to <persianYear> - 1; else set <cardinalYear> to <persianYear>; end 2. Set <dividend> to <cardinalYear> - 473. 3. Set <year> to (dividend mod 2820) + 474. 4. Return (((<year> + 38) * 682) mod 2816) < 682 Month Structure Month Days In Month Standard Year/Leap Year 1: Farvardin 31/31 2: Ordibehesht 31/31 3: Xordad 31/31 4: Tir 31/31 5: Mordad 31/31 6: Shahrivar 31/31 7: Mehr 30/30 8: Aban 30/30 9: Azar 30/30 10: Dey 30/30 11: Bahman 30/30 12: Esfand 29/30 Days In Year 365/366 The semantic month-key of a month is the same as the month's (English) name (as given here.) Pretty deep, right ? HTH, Sven Yes, the main website is down, but you should be able to load the code in Pharo 2.0 using the configuration. > -- > 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 kilon alios

Thats not only the Pharo, the Squeak, way, the Python way, the Ruby way ..... its the logical way GregorianDate >> toJulian You have a class then you have a method . You want to extend your method ? why increase the size of method ? You just create a new class for it. I have 3 rules when I code 1) Keep it small 2) Keep it simple 3) Keep it obvious Also I cant recommend this book highly enough, its not only the best book I have read, its a goldmine of concentrated wisdom. No vague theories, no assumptions, just a bombarbment of practical examples -> http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X it wont show you just proper naming it will show you everything. Its the kind of book that you will keep coming back to. This something that every coder should have. and yes Java is doing it wrong, its doing it very wrong. On Wed, Nov 13, 2013 at 10:19 AM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > On 11/13/2013 11:39, Bahman Movaqar wrote: > > On 11/13/2013 11:13, Bahman Movaqar wrote: > >> Let's say I have a method with signature in a language like Java as > below: > >> gregorianDayToJulianDay(year, month, day) > >> > >> What could be a proper naming for this method in Smalltalk? I'm a bit > >> confused as I'm so used to the concept of methods being "verbs" which > >> accept some arguments. > >> > >> I'd appreciate any help/idea. > > After reading Sven's reply, I came up with this design. Is it the > idiomatic way to handle this problem in Smalltalk: > > <pseudo-design> > class JulianConverter: > instance variable: 'day' > > #toGregorian > #toIranian > > class GregorianConverter: > instance variable: 'year month day' > > #toJulian > > class IranianConverter: > instance variable: 'year month day' > > #toJulian > > </pseudo-design> > > -- > 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 StÃ©phane Ducasse

did you check acancagua (unit and time) or chronos (more complete calendar) package Stef On Nov 13, 2013, at 9:19 AM, Bahman Movaqar <Bahman(a)BahmanM.com> wrote: > On 11/13/2013 11:39, Bahman Movaqar wrote: >> On 11/13/2013 11:13, Bahman Movaqar wrote: >>> Let's say I have a method with signature in a language like Java as below: >>> gregorianDayToJulianDay(year, month, day) >>> >>> What could be a proper naming for this method in Smalltalk? I'm a bit >>> confused as I'm so used to the concept of methods being "verbs" which >>> accept some arguments. >>> >>> I'd appreciate any help/idea. > > After reading Sven's reply, I came up with this design. Is it the > idiomatic way to handle this problem in Smalltalk: > > <pseudo-design> > class JulianConverter: > instance variable: 'day' > > #toGregorian > #toIranian > > class GregorianConverter: > instance variable: 'year month day' > > #toJulian > > class IranianConverter: > instance variable: 'year month day' > > #toJulian > > </pseudo-design> > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 13, 2013

Re: [Pharo-users] How to change background color

by Sergi Reyner

Ben, could you elaborate a bit on: add support for color on AbstractWidget > change a bit the way MorphicAdapters are built to take this color in account > I havenÂ´t quite figured out yet how do all the pieces fit together. It may be due to lack of caffeine though :) I have noticed that color sort of works... for example, you can inspect a SpecWindow, send it (self color: Color red) and the window will indeed change color, but as soon as you click on it it goes back to the default grey. Cheers, Sergi

Nov. 13, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Bernat Romagosa

Thanks a lot Torsten! I'll invest the whole morning tomorrow in trying to get a little bit more of this to work. If I don't succeed... there are lots of very good restaurants in Barcelona, Igor ;) 2013/11/13 Torsten Bergmann <astares(a)gmx.de> > Hi Bernat, > > >how do I translate this into NB code > > Either invite Igor (author of NB) for lunch or try this: > > > Its a C-structure, you convert it by wrapping this in a sublcass > of "NBExternalStructure". See the examples already in a Pharo 3.0 image. > > Basically you need: > > - define a subclass NBExternalStructure subclass: #WinNotifyIconData ... > - define the correct fields in a class side #fieldsDesc method according > to the native data types used in the structure > - call "WinNotifyIconData rebuildFieldAccessors" > - setup the types in a shared pool that you can include later: > > - define the pool: SharedPool subclass: #WinTryIconConstants ... > - in a class initialize method you can setup the type > > initialize > > NOTIFYICONDATA := #WinNotifyIconData. > PNOTIFYICONDATA:= 'NOTIFYICONDATA *'. > > - by including the pool you can use "NOTIFYICONDATA" or "PNOTIFYICONDATA" > in any native boost call. > > > If you are in Pharo 3.0 load "OS-Windows" package from the config browser. > Check the subclasses of NBExternalStructure there. > > I wrapped many other windows structures already so you can get an idea > about > it. For instance have a look at WinConsoleConstants>>initTypeConstants, > there you will find > the CONSOLE_CURSOR_INFO, CONSOLE_SCREEN_BUFFER_INFO structs wrapped in > WinConsoleCursor, WinConsoleScreenBuffer classes. > > Compare them with the MSDN struct description. > > >Could the Windows API be any more convoluted and dev-unfriendly in any > >possible sense? > > This question should go to M$ not Pharo-user ;) > > Bye > T. > > > BTW: I'm not sure "PNOTIFYICONDATA" alone will solve your problem if I > remember correctly > from my Smalltalk/MT and C/C++ times also playing with tray icons. > I guess you need a callback that gets called when the icon is clicked > or the tray icon menu > is choosen (see uCallbackMessage member in the struct). > You also need a handle to an icon - either the icon from the EXEs > resource section or > by loading one from a bitmap. That means wrapping the icon or bitmap > apis too... > > -- Bernat Romagosa.

Nov. 13, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by StÃ©phane Ducasse

JB can you read and reply to this mail? > Hi > > What Doru wrote pretty much sums it up. > > CodeCity under VW was based on JUN, which provided a programmer-friendly API built on top of OpenGL. Since there is no such thing under Pharo, when I later started to work on CodeCity under Pharo, I needed to learn about how to program directly to OpenGL. And the only example I had for that was SourceCity. In the meantime I manage to get a grip on my basic needs and was ready to move forward to implementing CodeCity. Now that does not work anymore in Pharo 3.0 so I am stuck. I could continue to program under Pharo 2.0, but what's the point? for now probably, because if you that is the one the most interested guy in that does not have the time to understand why others that do not need 3D should do it. NBOpenGL was a side project to give a try of busy people too. I'm sorry to say that but we cannot be on all fronts especially when they are changing. So can you tell us if you see what changed between 2 and 3. I have no idea. > I have already looked at Roassal 3d, but it was not easy to separate the API from the code. Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). Because Roassal 3d should not be about shadder but about 3D. > And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). Yes they changed the API and deprecated the old way of doing it. > So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. See below > Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. Three remarks: - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying on other people and probably frustrated when things are not working. - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you can get https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk Now again if nobody builds a jun like library in Pharo it will not exist. Stef > Cheers > Ricky > > > > > On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). > > I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? > > Cheers, > Doru > > > > On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Richard > > you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) > and his code should be split in two and one part should go to NBOpenGL. > Now he is experiencing some problem with NBOpenGL on windows as you. > > NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that > he does not have fun there). > > So it is important that you help because we are FULL > and sorry about that but really FULL. > > Ronie will visit us in January and share an office with igor. > > Stef > > > > Hi > > > > CodeCity, the project I am working on is based on NBOpenGL. > > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. > > > > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: > > > > GLTTRenderingDemo new openInWorld. > > > > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. > > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? > > > > Cheers > > Ricky > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 13, 2013