- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Feedback on Nautilus

by StÃ©phane Ducasse

which version are you using.... Alex can you report bugs in a way that we can immediately check and take actions. the icons are not definitive. > * Can I add a number of packages (based on regular expression?) to a group in one click? Have a look at the 'promote categories' command in OB. It is a bit boring to have to look for a particular package, especially when they are alphabetically ordered. It should be easy to do it. Now somebody should do it. > * What can be interesting, is to separate system packages from user packages, as it is done in many IDE. Currently, my packages Spy-* are represented the same way than Kernel. Putting system packages below user packages would improve the situation I feel. Maybe an option to not show system packages would be better. Yes that could be good. Now alphabetic order is better than mess > * Nautilus does not seem to work. (Only Nautilus2 does). I open Nautilus and clicking on a package opens an error. Maybe it will be better on one unique browser. This will make your life easier. Just focus on the one you use everyday. > > * The command "Add in Group ... " raises a DNU. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

May 25, 2011

[Pharo-project] Feedback on Nautilus

by Alexandre Bergel

Hi! * What the icon means? * Can I add a number of packages (based on regular expression?) to a group in one click? Have a look at the 'promote categories' command in OB. It is a bit boring to have to look for a particular package, especially when they are alphabetically ordered. * What can be interesting, is to separate system packages from user packages, as it is done in many IDE. Currently, my packages Spy-* are represented the same way than Kernel. Putting system packages below user packages would improve the situation I feel. Maybe an option to not show system packages would be better. * Nautilus does not seem to work. (Only Nautilus2 does). I open Nautilus and clicking on a package opens an error. Maybe it will be better on one unique browser. This will make your life easier. Just focus on the one you use everyday. * The command "Add in Group ... " raises a DNU. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 25, 2011

Re: [Pharo-project] cog vm for iOS

by Esteban Lorenzano

mmm... I'm seeing dr. geo (never did before, he), and I think a version of it as a single screen, like a game, who can popup cocoa dialogs (for copyright, etc.) could work. More or less a "mix" of first approach with John's approach. It can work for Dr.Geo but that is still a specific case... El 25/05/2011, a las 1:22p.m., Hilaire Fernandes escribiÃ³: > A third option could be to build a polymorph theme for iPAD. > This is an intermediate option I discussed a bit with Bert, to do a > DrGeo port for iPAD. > Frankly speaking if someone is interested to work with me on that > direction we may be able to produce something in our range and useful > for the community at large. > > Hilaire > > > > > Le 25/05/2011 18:01, Esteban Lorenzano a Ã©crit : >> Well... I'm going to use this post to talk a bit about Pharo in iOS, because it is more complex than "having a vm working" >> But first, a summary of where we stand: >> 1) The Stack VM is working with iPhone/iPad, but needs some minor adjustments (some tuning). >> One problem here is that I didn't integrate it to CMakeVMMaker (and as a consequence, to hudson), so build it is not a trivial task. But I will, as soon as some one jump and say "hey, I'm going to use it, for real!"... or as soon as I can find a free afternoon... it is planned (and I worked a little on this), but it is not a priority right now :) >> 2) The Cog (I mean, the jitter) will never work on iPad/iPhone, because of the apple license (clause 3.3.2) and because of the security sandbox policy. But I think the Stack VM can do a pretty job. No, I'm not going to prepare this just for recreational purposes because I do not have the time, and the community work I do should be spent in things the community can use... and I think that Eliot (who is, in fact, the one who can do this, I'm just a builder) will think similar :) >> >> So... if we have a vm running on iOS, why there is no a legion of fellow pharoers taking over the appstore? >> >> Well... because it is not enough. >> There are several problems, besides the vm working or not (to be fair, the interpreter vm works on iphone since at least two years, and John is the only one who succeed on pushing some nice smalltalk apps into the appstore). >> The main problem is that our morphic world is ok for desktop working, and some times for desktop commercial apps (like those of pinesoft), but it just can't be used to create real apps for the iPhone/iPad market. There are some exceptions, like some eToys work and probable the developing of games like "tic-tac-toe" or so... (I mean: graphic games who can be done with morphs). But as a general rule, you can't do a real app in pharo/squeak who runs in the iPhone/iPad and can be sold in the appstore. >> To overcome this problem, what John does is to create the full view in Cocoa, and "plug" the model to pharo/squeak images, using pharo as a module of a cocoa application. This can be done for several apps (and the fraction calculator is an example), but fails when you want a deeper interaction (because of the cost, not just in "programming time" but also the "translation time" between the cocoa app and pharo: it is just not good enough to bring a cool user experience (at least in all my experiments it was the case) >> >> There is another possible approach, who I think is the better in the long way, and that is what I was doing with Deimos project: using a bridge to construct, in pharo, real cocoa UI objects... the advantages with this are obvious. Nevertheless, there are also some problems with this approach: >> 1) last year I was working on this, and apple changed a clause. The result can be expressed as if they executed: 'deimos become: shit'. Months after they review the policy, but I was concentrated on Mars (the desktop equivalent to Deimos). I will continue this, but first I want to finish Mars, and also I need to solve the problem below: >> 2) there are also a performance problem with the ObjectiveC plugin and callbacks. In all my experiments, I never went below 70ms executing a callback from cocoa to pharo (and that's necessary, for example, to fill tables). The minimum time needed to have a cool "scroll" effect on tables is 40ms. Of course, iPhone 4 is better than 3gs... but the problem remains. The real thing is that ObjectiveC plugin relies on a semaphore communication model, and that's not good enough. So... I think the better approach here is to port FFI-Callback plugin (latest work of Eliot) to iOS. FFI-Callback plugin uses a whole different approach, who can overcome this performance issues (and some other who's not the case mention here). >> >> So... yes... I would love to finish this soon. But right now, other issues are top in priotity, and I just can't promise a release date. (Of course, the stackvm for iphone will be compiling on hudson some time soon... before ESUG for sure) >> >> hope this can explain all the status... :) >> >> cheers, >> Esteban >> >> El 25/05/2011, a las 11:56a.m., Igor Stasenko escribiÃ³: >> >>> On 25 May 2011 16:22, Steve Wirts <stevewirts(a)gmail.com> wrote: >>>> Hi All, >>>> Sorry if this topic has been covered in a previous email, I couldn't find >>>> anything conclusive so I'm posting it for my own clarity. >>>> I am a smalltalk programmer at heart but have been working in java at a java >>>> shop for sometime. Recently there's been a very strong directive from >>>> management to "get everything working on an iPad". >>>> I see a great opportunity to introduce pharo at the moment but need a way to >>>> deploy to iPad/iPhone devices. I'm not a c programmer and am overwhelmed at >>>> the thought of trying to build a cog vm for ios devices. >>>> >>>> Is there a binary package of cog vm for iPad/iPhone available somewhere? >>> >>> Ask Esteban! :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

May 25, 2011

Re: [Pharo-project] cog vm for iOS

by Esteban Lorenzano

Sorry, but no, this is not an option. A theme will never pass the apple quality check :( Esteban El 25/05/2011, a las 1:22p.m., Hilaire Fernandes escribiÃ³: > A third option could be to build a polymorph theme for iPAD. > This is an intermediate option I discussed a bit with Bert, to do a > DrGeo port for iPAD. > Frankly speaking if someone is interested to work with me on that > direction we may be able to produce something in our range and useful > for the community at large. > > Hilaire > > > > > Le 25/05/2011 18:01, Esteban Lorenzano a Ã©crit : >> Well... I'm going to use this post to talk a bit about Pharo in iOS, because it is more complex than "having a vm working" >> But first, a summary of where we stand: >> 1) The Stack VM is working with iPhone/iPad, but needs some minor adjustments (some tuning). >> One problem here is that I didn't integrate it to CMakeVMMaker (and as a consequence, to hudson), so build it is not a trivial task. But I will, as soon as some one jump and say "hey, I'm going to use it, for real!"... or as soon as I can find a free afternoon... it is planned (and I worked a little on this), but it is not a priority right now :) >> 2) The Cog (I mean, the jitter) will never work on iPad/iPhone, because of the apple license (clause 3.3.2) and because of the security sandbox policy. But I think the Stack VM can do a pretty job. No, I'm not going to prepare this just for recreational purposes because I do not have the time, and the community work I do should be spent in things the community can use... and I think that Eliot (who is, in fact, the one who can do this, I'm just a builder) will think similar :) >> >> So... if we have a vm running on iOS, why there is no a legion of fellow pharoers taking over the appstore? >> >> Well... because it is not enough. >> There are several problems, besides the vm working or not (to be fair, the interpreter vm works on iphone since at least two years, and John is the only one who succeed on pushing some nice smalltalk apps into the appstore). >> The main problem is that our morphic world is ok for desktop working, and some times for desktop commercial apps (like those of pinesoft), but it just can't be used to create real apps for the iPhone/iPad market. There are some exceptions, like some eToys work and probable the developing of games like "tic-tac-toe" or so... (I mean: graphic games who can be done with morphs). But as a general rule, you can't do a real app in pharo/squeak who runs in the iPhone/iPad and can be sold in the appstore. >> To overcome this problem, what John does is to create the full view in Cocoa, and "plug" the model to pharo/squeak images, using pharo as a module of a cocoa application. This can be done for several apps (and the fraction calculator is an example), but fails when you want a deeper interaction (because of the cost, not just in "programming time" but also the "translation time" between the cocoa app and pharo: it is just not good enough to bring a cool user experience (at least in all my experiments it was the case) >> >> There is another possible approach, who I think is the better in the long way, and that is what I was doing with Deimos project: using a bridge to construct, in pharo, real cocoa UI objects... the advantages with this are obvious. Nevertheless, there are also some problems with this approach: >> 1) last year I was working on this, and apple changed a clause. The result can be expressed as if they executed: 'deimos become: shit'. Months after they review the policy, but I was concentrated on Mars (the desktop equivalent to Deimos). I will continue this, but first I want to finish Mars, and also I need to solve the problem below: >> 2) there are also a performance problem with the ObjectiveC plugin and callbacks. In all my experiments, I never went below 70ms executing a callback from cocoa to pharo (and that's necessary, for example, to fill tables). The minimum time needed to have a cool "scroll" effect on tables is 40ms. Of course, iPhone 4 is better than 3gs... but the problem remains. The real thing is that ObjectiveC plugin relies on a semaphore communication model, and that's not good enough. So... I think the better approach here is to port FFI-Callback plugin (latest work of Eliot) to iOS. FFI-Callback plugin uses a whole different approach, who can overcome this performance issues (and some other who's not the case mention here). >> >> So... yes... I would love to finish this soon. But right now, other issues are top in priotity, and I just can't promise a release date. (Of course, the stackvm for iphone will be compiling on hudson some time soon... before ESUG for sure) >> >> hope this can explain all the status... :) >> >> cheers, >> Esteban >> >> El 25/05/2011, a las 11:56a.m., Igor Stasenko escribiÃ³: >> >>> On 25 May 2011 16:22, Steve Wirts <stevewirts(a)gmail.com> wrote: >>>> Hi All, >>>> Sorry if this topic has been covered in a previous email, I couldn't find >>>> anything conclusive so I'm posting it for my own clarity. >>>> I am a smalltalk programmer at heart but have been working in java at a java >>>> shop for sometime. Recently there's been a very strong directive from >>>> management to "get everything working on an iPad". >>>> I see a great opportunity to introduce pharo at the moment but need a way to >>>> deploy to iPad/iPhone devices. I'm not a c programmer and am overwhelmed at >>>> the thought of trying to build a cog vm for ios devices. >>>> >>>> Is there a binary package of cog vm for iPad/iPhone available somewhere? >>> >>> Ask Esteban! :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

May 25, 2011

Re: [Pharo-project] cog vm for iOS

by Hilaire Fernandes

A third option could be to build a polymorph theme for iPAD. This is an intermediate option I discussed a bit with Bert, to do a DrGeo port for iPAD. Frankly speaking if someone is interested to work with me on that direction we may be able to produce something in our range and useful for the community at large. Hilaire Le 25/05/2011 18:01, Esteban Lorenzano a Ã©crit : > Well... I'm going to use this post to talk a bit about Pharo in iOS, because it is more complex than "having a vm working" > But first, a summary of where we stand: > 1) The Stack VM is working with iPhone/iPad, but needs some minor adjustments (some tuning). > One problem here is that I didn't integrate it to CMakeVMMaker (and as a consequence, to hudson), so build it is not a trivial task. But I will, as soon as some one jump and say "hey, I'm going to use it, for real!"... or as soon as I can find a free afternoon... it is planned (and I worked a little on this), but it is not a priority right now :) > 2) The Cog (I mean, the jitter) will never work on iPad/iPhone, because of the apple license (clause 3.3.2) and because of the security sandbox policy. But I think the Stack VM can do a pretty job. No, I'm not going to prepare this just for recreational purposes because I do not have the time, and the community work I do should be spent in things the community can use... and I think that Eliot (who is, in fact, the one who can do this, I'm just a builder) will think similar :) > > So... if we have a vm running on iOS, why there is no a legion of fellow pharoers taking over the appstore? > > Well... because it is not enough. > There are several problems, besides the vm working or not (to be fair, the interpreter vm works on iphone since at least two years, and John is the only one who succeed on pushing some nice smalltalk apps into the appstore). > The main problem is that our morphic world is ok for desktop working, and some times for desktop commercial apps (like those of pinesoft), but it just can't be used to create real apps for the iPhone/iPad market. There are some exceptions, like some eToys work and probable the developing of games like "tic-tac-toe" or so... (I mean: graphic games who can be done with morphs). But as a general rule, you can't do a real app in pharo/squeak who runs in the iPhone/iPad and can be sold in the appstore. > To overcome this problem, what John does is to create the full view in Cocoa, and "plug" the model to pharo/squeak images, using pharo as a module of a cocoa application. This can be done for several apps (and the fraction calculator is an example), but fails when you want a deeper interaction (because of the cost, not just in "programming time" but also the "translation time" between the cocoa app and pharo: it is just not good enough to bring a cool user experience (at least in all my experiments it was the case) > > There is another possible approach, who I think is the better in the long way, and that is what I was doing with Deimos project: using a bridge to construct, in pharo, real cocoa UI objects... the advantages with this are obvious. Nevertheless, there are also some problems with this approach: > 1) last year I was working on this, and apple changed a clause. The result can be expressed as if they executed: 'deimos become: shit'. Months after they review the policy, but I was concentrated on Mars (the desktop equivalent to Deimos). I will continue this, but first I want to finish Mars, and also I need to solve the problem below: > 2) there are also a performance problem with the ObjectiveC plugin and callbacks. In all my experiments, I never went below 70ms executing a callback from cocoa to pharo (and that's necessary, for example, to fill tables). The minimum time needed to have a cool "scroll" effect on tables is 40ms. Of course, iPhone 4 is better than 3gs... but the problem remains. The real thing is that ObjectiveC plugin relies on a semaphore communication model, and that's not good enough. So... I think the better approach here is to port FFI-Callback plugin (latest work of Eliot) to iOS. FFI-Callback plugin uses a whole different approach, who can overcome this performance issues (and some other who's not the case mention here). > > So... yes... I would love to finish this soon. But right now, other issues are top in priotity, and I just can't promise a release date. (Of course, the stackvm for iphone will be compiling on hudson some time soon... before ESUG for sure) > > hope this can explain all the status... :) > > cheers, > Esteban > > El 25/05/2011, a las 11:56a.m., Igor Stasenko escribiÃ³: > >> On 25 May 2011 16:22, Steve Wirts <stevewirts(a)gmail.com> wrote: >>> Hi All, >>> Sorry if this topic has been covered in a previous email, I couldn't find >>> anything conclusive so I'm posting it for my own clarity. >>> I am a smalltalk programmer at heart but have been working in java at a java >>> shop for sometime. Recently there's been a very strong directive from >>> management to "get everything working on an iPad". >>> I see a great opportunity to introduce pharo at the moment but need a way to >>> deploy to iPad/iPhone devices. I'm not a c programmer and am overwhelmed at >>> the thought of trying to build a cog vm for ios devices. >>> >>> Is there a binary package of cog vm for iPad/iPhone available somewhere? >> >> Ask Esteban! :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > -- Education 0.2 -- http://blog.ofset.org/hilaire

May 25, 2011

[Pharo-project] [ANN] Dr. Geo II release 11.06

by Hilaire Fernandes

Announced there http://blog.ofset.org/hilaire/index.php?post/drgeo-11-06 The XO version of Dr. Geo II comes with the new COG Smalltalk Virtual Machine from Eliot Miranda, giving an average boost of +300% Feedback welcome! Enjoy Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

May 25, 2011

Re: [Pharo-project] cog vm for iOS

by Esteban Lorenzano

Well... I'm going to use this post to talk a bit about Pharo in iOS, because it is more complex than "having a vm working" But first, a summary of where we stand: 1) The Stack VM is working with iPhone/iPad, but needs some minor adjustments (some tuning). One problem here is that I didn't integrate it to CMakeVMMaker (and as a consequence, to hudson), so build it is not a trivial task. But I will, as soon as some one jump and say "hey, I'm going to use it, for real!"... or as soon as I can find a free afternoon... it is planned (and I worked a little on this), but it is not a priority right now :) 2) The Cog (I mean, the jitter) will never work on iPad/iPhone, because of the apple license (clause 3.3.2) and because of the security sandbox policy. But I think the Stack VM can do a pretty job. No, I'm not going to prepare this just for recreational purposes because I do not have the time, and the community work I do should be spent in things the community can use... and I think that Eliot (who is, in fact, the one who can do this, I'm just a builder) will think similar :) So... if we have a vm running on iOS, why there is no a legion of fellow pharoers taking over the appstore? Well... because it is not enough. There are several problems, besides the vm working or not (to be fair, the interpreter vm works on iphone since at least two years, and John is the only one who succeed on pushing some nice smalltalk apps into the appstore). The main problem is that our morphic world is ok for desktop working, and some times for desktop commercial apps (like those of pinesoft), but it just can't be used to create real apps for the iPhone/iPad market. There are some exceptions, like some eToys work and probable the developing of games like "tic-tac-toe" or so... (I mean: graphic games who can be done with morphs). But as a general rule, you can't do a real app in pharo/squeak who runs in the iPhone/iPad and can be sold in the appstore. To overcome this problem, what John does is to create the full view in Cocoa, and "plug" the model to pharo/squeak images, using pharo as a module of a cocoa application. This can be done for several apps (and the fraction calculator is an example), but fails when you want a deeper interaction (because of the cost, not just in "programming time" but also the "translation time" between the cocoa app and pharo: it is just not good enough to bring a cool user experience (at least in all my experiments it was the case) There is another possible approach, who I think is the better in the long way, and that is what I was doing with Deimos project: using a bridge to construct, in pharo, real cocoa UI objects... the advantages with this are obvious. Nevertheless, there are also some problems with this approach: 1) last year I was working on this, and apple changed a clause. The result can be expressed as if they executed: 'deimos become: shit'. Months after they review the policy, but I was concentrated on Mars (the desktop equivalent to Deimos). I will continue this, but first I want to finish Mars, and also I need to solve the problem below: 2) there are also a performance problem with the ObjectiveC plugin and callbacks. In all my experiments, I never went below 70ms executing a callback from cocoa to pharo (and that's necessary, for example, to fill tables). The minimum time needed to have a cool "scroll" effect on tables is 40ms. Of course, iPhone 4 is better than 3gs... but the problem remains. The real thing is that ObjectiveC plugin relies on a semaphore communication model, and that's not good enough. So... I think the better approach here is to port FFI-Callback plugin (latest work of Eliot) to iOS. FFI-Callback plugin uses a whole different approach, who can overcome this performance issues (and some other who's not the case mention here). So... yes... I would love to finish this soon. But right now, other issues are top in priotity, and I just can't promise a release date. (Of course, the stackvm for iphone will be compiling on hudson some time soon... before ESUG for sure) hope this can explain all the status... :) cheers, Esteban El 25/05/2011, a las 11:56a.m., Igor Stasenko escribiÃ³: > On 25 May 2011 16:22, Steve Wirts <stevewirts(a)gmail.com> wrote: >> Hi All, >> Sorry if this topic has been covered in a previous email, I couldn't find >> anything conclusive so I'm posting it for my own clarity. >> I am a smalltalk programmer at heart but have been working in java at a java >> shop for sometime. Recently there's been a very strong directive from >> management to "get everything working on an iPad". >> I see a great opportunity to introduce pharo at the moment but need a way to >> deploy to iPad/iPhone devices. I'm not a c programmer and am overwhelmed at >> the thought of trying to build a cog vm for ios devices. >> >> Is there a binary package of cog vm for iPad/iPhone available somewhere? > > Ask Esteban! :) > > -- > Best regards, > Igor Stasenko AKA sig.

May 25, 2011

Re: [Pharo-project] [Seaside] Re: ESUG SummerTalk - Fuel, binary object serializer

by Mariano Martinez Peck

On Wed, May 25, 2011 at 5:31 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 25/05/11 11:22 AM, Mariano Martinez Peck wrote: > >> >> - globals behaviors (classes and traits) are managed (by default) in >> kind of "light" serialization. Where we only serialize the global name >> which means that the class has to be present in Smalltalk globals in the >> image that you want to materialize. >> >> You can change the default behavior and be able to completely serialize >> a class/trait. But this is much more complicated and it is still work on >> process (ClassBuilder is not your best friend). >> > > Okay. I think all that is needed is a "safe mode" option when > *de-serializing*, which would discard any non-light classes or global > objects that appear in the stream. > > > Sorry Yanni, I didn't follow. Could you please explain a bit more? what do you want to serialize? do you want to be able to choose some classes as light and some as non-light? where do you want to materialize ? in the same image or in another one ? When you said discard....what would you do with the instances of those non-light classes for example? you don't materialize them? and what happens to the objects that were pointing to them ? why would be the scenario useful for ? security ? Thanks -- Mariano http://marianopeck.wordpress.com

May 25, 2011

Re: [Pharo-project] Questions of understanding

by Igor Stasenko

On 25 May 2011 17:30, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > >> I have no idea. Maybe someone in the VM mailing list can help you. >> > Ok I Â finally got the serialPort access under Cog VM and Linux > I concede it is currently a hackerish solution a combination out of > Squeak sources and Cog sources with a good mixture of Cog > > So whomever may be "reponsible" can get in touch with me and I'll try to > work out a stable implementation on Linux. > > But I think there are a few problems with Pharo 1.3 and Cog. AFAIKT one > needs AbstractLauncher. I shamlessly stole it from Squeak. If I do > not have it and start my generated CogVM I just get an open window with > some black rectangle Â in the upper left. > This problem was Â mentioned at: > > http://code.google.com/p/pharo/issues/detail?id=4002 > > Now what did I have to do? > I downloaded the sources from squeak-vm and Cog and there are at least > two different C files and probably a header files with the prototyps: > The two files are > sqUnixSerial.c which is in Â platforms/unix/plugins/SerialPlugin > SerialPlugin in src/plugins/SerialPlugin > > It seems the first is the handwritten C-code > > The first is needed to "offer" the functionality and the later is > probabl seems t be the interface to Squeak. I guess this is generated > code from some Slang code which looks like this: > > parityType dataBits: dataBits inFlowControlType: inFlowControl outFlowControlType: outFlowControl xOnByte: xOnChar xOffByte: xOffChar > > Â Â Â Â | cString | > Â Â Â Â self primitive: 'primitiveSerialPortOpenByName' > Â Â Â Â Â Â Â Â parameters: #(ByteArray SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger ). > Â Â Â Â self var: #cString type: 'char *'. > Â Â Â Â cString := self allocateTerminatedString: deviceName. > Â Â Â Â self cCode: 'serialPortOpenByName( > Â Â Â Â Â Â Â Â Â Â Â Â cString, baudRate, stopBitsType, parityType, dataBits, > Â Â Â Â Â Â Â Â Â Â Â Â inFlowControl, outFlowControl, xOnChar, xOffChar)' > > which then write out the proper C code for that plugin. > > You see I'm still ignorant on how this is all supposed to work. > > Nevertheless copying the files at the proper places in the src and > platform tree. This codes get's compiled into the VirtualMachine. > > And I can use this "machine" for accessing the serial interfaces, (it > even works for '/dev/ttyUSBx' devices. For me this is a great thing > because I'm forced to access some periperal devices via serial lines. > > I need some extra hack in the generated file (I know this is "dirty" a > missing #define was introduced. I bet there is a better place for that > but in genrated code. But well it's Â just an intermediate step. > > If someone here may be interested just drop me a mail and with some help > we'll be able to modify the Cog sources cleanly to use this modified > Plugin for intefacing to serial lines in Linux. > In order to answer this question we have to see what you did. And for that, it would be good if you register on gitorious.org and then clone VM sources into your own branch and then push your changes there. Then we can analyze it and integrate into a main branch. > I'm also quite aware that the Smalltalk side of the code could need a > little attention: It looks like: > > > nextPutAll: aStringOrByteArray > Â Â Â Â "Send the given bytes out this serial port. The port must be > Â Â Â Â open. " > Â Â Â Â ^ port isString > Â Â Â Â Â Â Â Â ifTrue: [self > Â Â Â Â Â Â Â Â primWritePortByName: port > Â Â Â Â Â Â Â Â from: aStringOrByteArray > Â Â Â Â Â Â Â Â startingAt: 1 > Â Â Â Â Â Â Â Â count: aStringOrByteArray size] > Â Â Â Â Â Â Â Â ifFalse: [self > Â Â Â Â Â Â Â Â primWritePort: port > Â Â Â Â Â Â Â Â from: aStringOrByteArray > Â Â Â Â Â Â Â Â startingAt: 1 > Â Â Â Â Â Â Â Â count: aStringOrByteArray size] > > Which is kind of "unproper" IMHO.... > Please, create an issue on Cog issue tracker and place a changeset for language side changes there. You can also use that issue entry to describe your changes and point to the VM-side source code which you are changed. http://code.google.com/p/cog/issues/list Otherwise there is a risk, that your changes and comments will be buried under tons of other mails and will be lost. P.S. it is great that you were able to fix plugin & build VM with little help. If you have questions, do not hesitate to ask. We need people who are not afraid to get their hands dirty and to fix something in VM :) -- Best regards, Igor Stasenko AKA sig.

May 25, 2011

Re: [Pharo-project] Questions of understanding

by Mariano Martinez Peck

But I think there are a few problems with Pharo 1.3 and Cog. AFAIKT one > needs AbstractLauncher. I shamlessly stole it from Squeak. If I do > not have it and start my generated CogVM I just get an open window with > some black rectangle in the upper left. > This problem was mentioned at: > > http://code.google.com/p/pharo/issues/detail?id=4002 > > yes. Cog doesn't load in Pharo 1.3 anymore. We will fix it. > Now what did I have to do? > I downloaded the sources from squeak-vm and Cog and there are at least > two different C files and probably a header files with the prototyps: > The two files are > sqUnixSerial.c which is in platforms/unix/plugins/SerialPlugin > SerialPlugin in src/plugins/SerialPlugin > > It seems the first is the handwritten C-code > yes, everything under /platform is the hand written part and known as "platform code" > > The first is needed to "offer" the functionality and the later is > probabl seems t be the interface to Squeak. I guess this is generated > code from some Slang code yes, and that's what is known as "VM sources", the auto generated C code from SLANG that is usually placed in /src > which looks like this: > > parityType dataBits: dataBits inFlowControlType: inFlowControl > outFlowControlType: outFlowControl xOnByte: xOnChar xOffByte: xOffChar > > | cString | > self primitive: 'primitiveSerialPortOpenByName' > parameters: #(ByteArray SmallInteger SmallInteger > SmallInteger SmallInteger SmallInteger SmallInteger SmallInteger > SmallInteger ). > self var: #cString type: 'char *'. > cString := self allocateTerminatedString: deviceName. > self cCode: 'serialPortOpenByName( > cString, baudRate, stopBitsType, parityType, > dataBits, > inFlowControl, outFlowControl, xOnChar, xOffChar)' > > which then write out the proper C code for that plugin. > > yep > You see I'm still ignorant on how this is all supposed to work. > > so do I :) > Nevertheless copying the files at the proper places in the src and > platform tree. This codes get's compiled into the VirtualMachine. > > And I can use this "machine" for accessing the serial interfaces, (it > even works for '/dev/ttyUSBx' devices. For me this is a great thing > because I'm forced to access some periperal devices via serial lines. > > I need some extra hack in the generated file (I know this is "dirty" a > missing #define was introduced. I bet there is a better place for that > but in genrated code. But well it's just an intermediate step. > > If someone here may be interested just drop me a mail and with some help > we'll be able to modify the Cog sources cleanly to use this modified > Plugin for intefacing to serial lines in Linux. > Eliot should be interested. But you didn't comment your changes. Maybe you can push them in git ? > > I'm also quite aware that the Smalltalk side of the code could need a > little attention: It looks like: > > > > nextPutAll: aStringOrByteArray > "Send the given bytes out this serial port. The port must be > open. " > ^ port isString > ifTrue: [self > primWritePortByName: port > from: aStringOrByteArray > startingAt: 1 > count: aStringOrByteArray size] > ifFalse: [self > primWritePort: port > from: aStringOrByteArray > startingAt: 1 > count: aStringOrByteArray size] > > > for this you can open a pharo issue -- Mariano http://marianopeck.wordpress.com

May 25, 2011