November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Opening a serial Port with Pharo on Linux

by Esteban Lorenzano

we fixed that with Luc in the sprint last friday :) problem was: 1) for linux, primitive openByName: was never implemented. 2) for OSX, all the plugin was never implemented, there was just a stub. So well, we implemented all of that, now... you need the latest VM build. but I'm afraid right now jenkins is experimenting some problems and not online. Just wait a few hours and you will be able to download it :) Esteban On Nov 7, 2012, at 3:54 PM, Friedrich Dominicus <frido(a)q-software-solutions.de> wrote: > I'm stuck. I try to open a serial Port on Linux using Pharo. > > The code is as simple as: > > port := SerialPort new. > portName := '/dev/ttyUSB0'. > port openPort: portName. > > Now this opening fails for "whatever" reason. > Anyway in the console I got the following "messages": > > PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] > Error while opening the serial port (/dev/ttyUSB0#4 > ). > Error: Cannot open '/dev/ttyUSB0' > > It seems after the USB0 there is not the "end" of the string but some > gibberish. > > I tried to extract the code for the SerialPlugin and use it stand-alone > in C andwrote the following: > > #include <stdio.h> > #include "SerialPlugin.h" > > > int main(void) { > char *portName = "/dev/ttyUSB0"; > int baudRate = 9600; > int stopBitsType = 1; > int parityType = 0; > int dataBits = 8; > int inFlowControlType = 0; > int outFlowControlType = 0; > int xOnByte = 19; > int xOffByte = 24; > int iRval; > > > iRval = serialPortOpenByName (portName, > baudRate, stopBitsType, parityType, > dataBits, inFlowControlType, outFlowControlType, > xOnByte, xOffByte); > iRval = serialPortCloseByName (portName); > return 0; > } > > And there is no error while using it this way in C. So what > is broken? > > Regards > Friedrich >

Nov. 7, 2012

[Pharo-project] Opening a serial Port with Pharo on Linux

by Friedrich Dominicus

I'm stuck. I try to open a serial Port on Linux using Pharo. The code is as simple as: port := SerialPort new. portName := '/dev/ttyUSB0'. port openPort: portName. Now this opening fails for "whatever" reason. Anyway in the console I got the following "messages": PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] Error while opening the serial port (/dev/ttyUSB0#4 ). Error: Cannot open '/dev/ttyUSB0' It seems after the USB0 there is not the "end" of the string but some gibberish. I tried to extract the code for the SerialPlugin and use it stand-alone in C andwrote the following: #include <stdio.h> #include "SerialPlugin.h" int main(void) { char *portName = "/dev/ttyUSB0"; int baudRate = 9600; int stopBitsType = 1; int parityType = 0; int dataBits = 8; int inFlowControlType = 0; int outFlowControlType = 0; int xOnByte = 19; int xOffByte = 24; int iRval; iRval = serialPortOpenByName (portName, baudRate, stopBitsType, parityType, dataBits, inFlowControlType, outFlowControlType, xOnByte, xOffByte); iRval = serialPortCloseByName (portName); return 0; } And there is no error while using it this way in C. So what is broken? Regards Friedrich

Nov. 7, 2012

Re: [Pharo-project] [Pharo-consortium] Pharo consortium agreement

by StÃ©phane Ducasse

> So, what's best. Wait to finalize the form or print and send? so far it will only be c instead of C so wait 2 more days and this is ok Stef > > Norbert > > Am 06.11.2012 um 17:24 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Dear Pharoers >> >> Here is the result of the work we did around the consortium for Pharo for about 2 years. We took into account all your remarks over the years >> and we think that the result is good and corresponds to what the community can support. >> This consortium is important for Pharo's future and it will help us to deliver a system to help you making business. >> Our goal is to be able to collect fundings to pay at least one full time engineer. >> >> The idea is that all the consortium members will sign the same agreement. We will not handle modifications per partners. >> Now since we are starting the process if you spot some glitches on the form let us know. We can discuss and fully stabilize one version. >> >> We suggest to read the document. >> - If you agree to sign it and send it to us (in two copies if you do it by surface mail at >> INRIA - S. Ducasse - Pharo, 40, avenue Halley, Parc Scientifique de la Haute Borne, >> BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.), so that we sign it too. >> - Don't forget to complete your legal mention on first page and your contact details on article 14 before signing. :) >> >> We will launch soon two web sites: >> - one for the Pharo user association and >> - one for the Pharo consortium. >> >> >> A side note: we will communicate about it later and separately but Inria decided to support the consortium by paying one extra year to Igor Stasenko. >> This is around 60 Keuros in addition to the year of Esteban Lorenzano and previous years of Igor. >> >> I really want to thank Inria for the constant support and the work of S. Karpf, P. Moreau and S. Perin. >> >> Stef >> >> <2012-11-06-consortium PHARO.pdf> >> >> >> >> >> ------------------------ >> Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) >> INRIA - USTL - CNRS UMR 8022 >> stephane.ducasse(a)inria.fr >> http://stephane.ducasse.free.fr >> http://rmod.lille.inria.fr/ >> **NEW ***Tel 00 33 (0)3 59 35 87 52 - Fax 33 3 59 57 78 50 >> >> 40, avenue Halley, Parc Scientifique de la Haute Borne, >> BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. >> >> >> >> >> >> >> >> _______________________________________________ >> Pharo-consortium mailing list >> Pharo-consortium(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-consortium >

Nov. 7, 2012

[Pharo-project] [Jenkins] Failing tests 2.0

by Marcus Denker

Issue 6929: Undeclared ManifestManifestResourcesTests http://code.google.com/p/pharo/issues/detail?id=6929 Issue 6927: Failing test for Manifest http://code.google.com/p/pharo/issues/detail?id=6927 Issue 6928: Obsolete class after running all tests http://code.google.com/p/pharo/issues/detail?id=6928 Issue 6309: Failing test on Windows related to SocketStream http://code.google.com/p/pharo/issues/detail?id=6309 -- Marcus Denker -- http://marcusdenker.de

Nov. 7, 2012

Re: [Pharo-project] SqueakSource Mails

by Tobias Pape

Am 07.11.2012 um 14:03 schrieb Sven Van Caekenberghe: > Guys, > > I am receiving hundreds of old commit emails from SqueakSource since the latest restart. This happened before as well. Is anybody else seeing this as well ? And can something be done about this ? > > Sven I see them as well. As far as I know SqueakSource, the only option is to disable Commit mails for your project altogether. Best -Tobias

Nov. 7, 2012

Re: [Pharo-project] SqueakSource Mails

by Fabrizio Perin

Hi Sven, it happened to me too. not sure what the right solution is. It will eventually stop. what you can do is to unregister yourself from receiveing commit email notifications. Cheers, Fabrizio 2012/11/7 Sven Van Caekenberghe <sven(a)stfx.eu>: > Guys, > > I am receiving hundreds of old commit emails from SqueakSource since the latest restart. This happened before as well. Is anybody else seeing this as well ? And can something be done about this ? > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Nov. 7, 2012

Re: [Pharo-project] [Pharo-consortium] Pharo consortium agreement

by Norbert Hartl

So, what's best. Wait to finalize the form or print and send? Norbert Am 06.11.2012 um 17:24 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Dear Pharoers > > Here is the result of the work we did around the consortium for Pharo for about 2 years. We took into account all your remarks over the years > and we think that the result is good and corresponds to what the community can support. > This consortium is important for Pharo's future and it will help us to deliver a system to help you making business. > Our goal is to be able to collect fundings to pay at least one full time engineer. > > The idea is that all the consortium members will sign the same agreement. We will not handle modifications per partners. > Now since we are starting the process if you spot some glitches on the form let us know. We can discuss and fully stabilize one version. > > We suggest to read the document. > - If you agree to sign it and send it to us (in two copies if you do it by surface mail at > INRIA - S. Ducasse - Pharo, 40, avenue Halley, Parc Scientifique de la Haute Borne, > BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.), so that we sign it too. > - Don't forget to complete your legal mention on first page and your contact details on article 14 before signing. :) > > We will launch soon two web sites: > - one for the Pharo user association and > - one for the Pharo consortium. > > > A side note: we will communicate about it later and separately but Inria decided to support the consortium by paying one extra year to Igor Stasenko. > This is around 60 Keuros in addition to the year of Esteban Lorenzano and previous years of Igor. > > I really want to thank Inria for the constant support and the work of S. Karpf, P. Moreau and S. Perin. > > Stef > > <2012-11-06-consortium PHARO.pdf> > > > > > ------------------------ > Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) > INRIA - USTL - CNRS UMR 8022 > stephane.ducasse(a)inria.fr > http://stephane.ducasse.free.fr > http://rmod.lille.inria.fr/ > **NEW ***Tel 00 33 (0)3 59 35 87 52 - Fax 33 3 59 57 78 50 > > 40, avenue Halley, Parc Scientifique de la Haute Borne, > BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France. > > > > > > > > _______________________________________________ > Pharo-consortium mailing list > Pharo-consortium(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-consortium

Nov. 7, 2012

Re: [Pharo-project] Replace ByteArray with a smaller one

by Camillo Bruni

if the chunks you wan to cut off are big enough you could potentially allocate a new object there which get's gc-ed. But I have no clue how to do that without VM / NB support ;) On 2012-11-07, at 14:39, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I have a ByteArray of size N. > And I want now only the same ByteArray but from 1 to N-X. I am using > #copyFrom:to: but that one answers a new copy. If the ByteArray is large, > this takes time because it needs to allocate a large object. In my case I > don't care and I can modify the original ByteArray itself (lets say make it > smaller, null the remaining part and change the object header info). That > way I would avoid an extra allocation. Is there a primitive for that? > > Thanks! > > -- > Mariano > http://marianopeck.wordpress.com

Nov. 7, 2012

Re: [Pharo-project] Cheating NB FFI ByteArray size

by Camillo Bruni

just never forget that we have a moving GC! ;) so directly passing references to native function can be quite dangerous! Otherwise you could first manually adjust the start address by writing the corresponding ASM code ;) then run the C callout. I should check if we already have a proper helper method for that. On 2012-11-07, at 14:33, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Igor. I wonder if I can do the following. > I have to pass a ByteArray to a function that expects an already malloced > char*. > So far it is working fine. Now...what I would like is from the image side > to allocate a ByteArray of size + 4. I need to reserve the first 4 bytes of > the ByteArray for something. But the library I am calling doesn't let me > specify where to start from that char*. > So...can I cheat? I mean, can I allocate ByteArray+4 in the image, but when > passing it as an argument somehow say "ok, take this ByteArray but think > the the beginning is the byte 4" ? > or something like that ? > > Thanks! > > -- > Mariano > http://marianopeck.wordpress.com

Nov. 7, 2012

[Pharo-project] Replace ByteArray with a smaller one

by Mariano Martinez Peck

Hi guys. I have a ByteArray of size N. And I want now only the same ByteArray but from 1 to N-X. I am using #copyFrom:to: but that one answers a new copy. If the ByteArray is large, this takes time because it needs to allocate a large object. In my case I don't care and I can modify the original ByteArray itself (lets say make it smaller, null the remaining part and change the object header info). That way I would avoid an extra allocation. Is there a primitive for that? Thanks! -- Mariano http://marianopeck.wordpress.com

Nov. 7, 2012