Re: [Pharo-users] encoding challenge
Hi, If you are interested in ASN.1, there is an implementation of that as part of the SS7 project: CI Server is here: https://ci.hartl.name/job/ASN.1/ This implements a ASN.1 parser. This means you do not have to do the encoding yourself but you can use the ASN.1 as published. Very useful when implementing protocols that are specified using ASN.1, e.g. all the telephony stuff for mobile networks. If it makes sense to use in this context I am not sure. Marcus > On 19 Dec 2015, at 09:22, Robert Withers wrote: > > It turns out my problem was elsewhere. These convert just fine. > > My issue is the combination of flipping the whole stack to frames and adding > headers and header method calls down at the Transport layer. The session > layer is actually 2 sub-layers, data on top of control. In this case, we need > a data frame but no control frame, so the transport is frameless. It is > blowing up on me because control messages have an artificial frame. > > I will look into Asn1Der encoding of the control messages, however. > > cheers,, > robert > > On 12/19/2015 01:09 AM, Robert Withers wrote: >> A core part of communications, whether online or to persistence, is >> encoding, or marshalling. Let's do an example! Thank you for your >> thoughtful, earnest participation, as God wills it. >> >> Here are 2 methods that encode and decode a DateAndTime object, but rather >> poorly. I've been going without much sleep for a bit and I can't figure it >> out. Here is the code in hopes that some will find this an interesting >> exercise in team and community building. For that intention, as a beginning. >> What's the best solution? >> >> Let's show them how to code when given the space in the environment. Tnks! >> :) >> >> In class ASN1UTCTimeType.. >> >> encodeValue: anObject withDERStream: derStream >> >>| yy mo dd hh mm ss utcDateTime | >>yy := anObject year asString copyFrom: 3 to: 4. >>mo := anObject month asString padded: #left to: 2 with: $0. >>dd := anObject dayOfMonth asString padded: #left to: 2 with: $0. >>hh := anObject hour asString padded: #left to: 2 with: $0. >>mm := anObject minute asString padded: #left to: 2 with: $0. >>ss := anObject seconds asString padded: #left to: 2 with: $0. >>utcDateTime := (yy, mo, dd, hh, mm, ss, 'Z') asByteArray. >>derStream nextPutAll: utcDateTime. >> >> >> >> decodeValueWithDERStream: derStream length: length >> >>| aUTCDateTime | >>aUTCDateTime := (derStream next: length) asByteArray asString. >>^ (DateAndTime readFromString: ( >>((aUTCDateTime copyFrom: 1 to: 2) asInteger > 50 ifTrue: ['19'] >> ifFalse: ['20']), >>(aUTCDateTime copyFrom: 1 to: 2), '-', >>(aUTCDateTime copyFrom: 3 to: 4), '-', >>(aUTCDateTime copyFrom: 5 to: 6), 'T', >>(aUTCDateTime copyFrom: 7 to: 8), ':', >>(aUTCDateTime copyFrom: 9 to: 10), ':', >>(aUTCDateTime copyFrom: 11 to: 12))) >>offset: 0 >> >> > > -- > . .. .. ^,^ robert >
[Pharo-users] [Question] Inspecting a collection of strings in Pharo 5 -- edit pane for a string?
Hello I am inspecting a collection of strings in Pharo 5. I wonder how I get at an edit pane to modify a particular string? Thank you for the answer in advance --Hannes
[Pharo-users] Where is the documentation for the FFI ?
I am considering porting my python bridge from sockets to a C DLL , but I cant find documentation for the Pharo FFI , where is it ?
[Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort
Dear all, I am tremendously happy to announce you that Pharo Consortium will sponsor yet another development effort. In this particular case, it's my honor to carry on such an effort and I will be developing and improving a few things and ideas. All the contract and paperwork has already been done so it's time to start working. Regarding the developments itself, we discussed about these topics: 1) Experiment with a simpler yet more limited OSProcess alternative to execute OS commands. 2) Improving FileSystem in order to better deal with some POSIX stuff like symbolic links, unix file permissions, etc etc. I have already started with 1). OSProcess is super complete and it involves some packages (OSProcess / CommandShell) as well as some VM plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features (like forking the running image) but we would like to focus only in executing OS commands. In addition, OSProcess dates from quite some years ago when many of the current infrastructure features did not exist yet. So the idea is to think a simpler alternative to execute OS commands, using new features such as threaded FFI (for example, for reading async from pipes), pinned objects, etc. We want to use FFI as much as possible rather than VM plugins. >From the image side, we are thinking about an API which would look like a builder-like API (FileSystem, XStream, etc). We have been discussing with David Lewis (OSProcess author) as well as with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc in order to agree in a project that would be worth doing (otherwise we would continue using existing tools). And they have all been very kind with me providing positive discussions. I will soon do a survey to measure the most common use cases of OSProcess and related tools. If you have any thought, question, feedback, or whatever, please let us know. Finally, note that I will be doing this project together with another client's project (Quuve) and my life does not have much free time these days...so please be patient!!! Best, -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort
I am very excited for such a project. I hope you manage to fix the stdout problem on macos. One thing I would like to see is an expansion of the ability of OSProcess to launch multiple instances of pharo and make them communicate with each other. Thats a way to have pharo running on multiple cores. Maybe establish a framework of communication of images that will be based on the existing design of the fork mechanism in Pharo. Python is doing something similar with multiprocessing module which launches multiple processes of cpython executable and makes them communication with each other through a similar api to its threading module. This way python takes advantage of multiple cores. Python threads like pharo are green threads and pharo like python has a GIL like mechanism. Taking into account that current computers have at least 4 cores, its not a bad idea to speed up pharo like this at least 400% ;) On Sat, Dec 19, 2015 at 3:24 PM Mariano Martinez Peck wrote: > Dear all, > > I am tremendously happy to announce you that Pharo Consortium will sponsor > yet another development effort. In this particular case, it's my honor to > carry on such an effort and I will be developing and improving a few things > and ideas. All the contract and paperwork has already been done so it's > time to start working. > > Regarding the developments itself, we discussed about these topics: > > 1) Experiment with a simpler yet more limited OSProcess alternative to > execute OS commands. > 2) Improving FileSystem in order to better deal with some POSIX stuff like > symbolic links, unix file permissions, etc etc. > > I have already started with 1). OSProcess is super complete and it > involves some packages (OSProcess / CommandShell) as well as some VM > plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features > (like forking the running image) but we would like to focus only in > executing OS commands. In addition, OSProcess dates from quite some years > ago when many of the current infrastructure features did not exist yet. > > So the idea is to think a simpler alternative to execute OS commands, > using new features such as threaded FFI (for example, for reading async > from pipes), pinned objects, etc. We want to use FFI as much as possible > rather than VM plugins. > > From the image side, we are thinking about an API which would look like a > builder-like API (FileSystem, XStream, etc). > > We have been discussing with David Lewis (OSProcess author) as well as > with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc > in order to agree in a project that would be worth doing (otherwise we > would continue using existing tools). And they have all been very kind with > me providing positive discussions. > > I will soon do a survey to measure the most common use cases of OSProcess > and related tools. > > If you have any thought, question, feedback, or whatever, please let us > know. > > Finally, note that I will be doing this project together with another > client's project (Quuve) and my life does not have much free time these > days...so please be patient!!! > > Best, > > -- > Mariano > http://marianopeck.wordpress.com >
[Pharo-users] install on ubuntu 15.10 from PPA should work?
--- Begin Message --- Reading package lists... Done phm@elitebook:~$ sudo apt-get install pharo-vm-core Reading package lists... Done Building dependency tree Reading state information... Done Package pharo-vm-core:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'pharo-vm-core:i386' has no installation candidate phm@elitebook:~$ uname -a Linux elitebook 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux phm@elitebook:~$ --- End Message ---
Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort
Could you guys look at how to fix mouse clicks so the select first time and stay selected. I have noticed some delay and clicks don't do whjat I expect smoothly. I do not know if others know what I am talking about. Snyways, it sounds like great fun, hopefully one happenss near me, either here or on the road. Thanks! robert On 12/19/2015 08:23 AM, Mariano Martinez Peck wrote: Dear all, I am tremendously happy to announce you that Pharo Consortium will sponsor yet another development effort. In this particular case, it's my honor to carry on such an effort and I will be developing and improving a few things and ideas. All the contract and paperwork has already been done so it's time to start working. Regarding the developments itself, we discussed about these topics: 1) Experiment with a simpler yet more limited OSProcess alternative to execute OS commands. 2) Improving FileSystem in order to better deal with some POSIX stuff like symbolic links, unix file permissions, etc etc. I have already started with 1). OSProcess is super complete and it involves some packages (OSProcess / CommandShell) as well as some VM plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features (like forking the running image) but we would like to focus only in executing OS commands. In addition, OSProcess dates from quite some years ago when many of the current infrastructure features did not exist yet. So the idea is to think a simpler alternative to execute OS commands, using new features such as threaded FFI (for example, for reading async from pipes), pinned objects, etc. We want to use FFI as much as possible rather than VM plugins. From the image side, we are thinking about an API which would look like a builder-like API (FileSystem, XStream, etc). We have been discussing with David Lewis (OSProcess author) as well as with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc in order to agree in a project that would be worth doing (otherwise we would continue using existing tools). And they have all been very kind with me providing positive discussions. I will soon do a survey to measure the most common use cases of OSProcess and related tools. If you have any thought, question, feedback, or whatever, please let us know. Finally, note that I will be doing this project together with another client's project (Quuve) and my life does not have much free time these days...so please be patient!!! Best, -- Mariano http://marianopeck.wordpress.com -- . .. .. ^,^ robert
Re: [Pharo-users] [Question] Inspecting a collection of strings in Pharo 5 -- edit pane for a string?
Hi, Strings are supposed to be immutable, and that is why we do not support editing by default :). If you would want to provide editing tools for a String, you would need to create a new inspector extension. This would probably be a bit cumbersome because you would probably have to work with basic things like String>>at:put:. A different way would be to not work with Strings directly, but with some wrapper objects that hold those strings. In this case, it would be easy to replace the wrapped string every time the editor changes. Cheers, Doru > On Dec 19, 2015, at 11:53 AM, H. Hirzel wrote: > > Hello > > I am inspecting a collection of strings in Pharo 5. > > I wonder how I get at an edit pane to modify a particular string? > > Thank you for the answer in advance > > --Hannes > -- www.tudorgirba.com www.feenk.com “Live like you mean it."
[Pharo-users] Morphic video tutorials
I decided to start making a series of video tutorial that will focus on Morphic and the things I have learned with making my own custom GUIs here is the first one and its playlist where i will add future ones https://www.youtube.com/playlist?list=PLqbtQ7OkSta3KLEEwdxVk0ySoJsP32-dz
Re: [Pharo-users] Morphic video tutorials
On 19/12/15 22:39, Dimitris Chloupis wrote: I decided to start making a series of video tutorial that will focus on Morphic and the things I have learned with making my own custom GUIs here is the first one and its playlist where i will add future ones https://www.youtube.com/playlist?list=PLqbtQ7OkSta3KLEEwdxVk0ySoJsP32-dz Nice. Great to hear about your design considerations and where you find things. Stephan
Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Consortium Sponsored Development Effort
Hi Mariano, have a look at my OS- project and packages. Especially for Windows. It includes support for executing a process, console, ... www.smalltalkhub.com/#!/~OS The idea is that we have a layer on top of an FFI to access the native platform. In a similar way in the different environments - but still with anything the platform has to offer. It works in Pharo 4 and Pharo 5 up to Spur as it is based on NB. Need to adopt it to the new FFI still. Bye T. Gesendet: Samstag, 19. Dezember 2015 um 14:23 Uhr Von: "Mariano Martinez Peck" An: "Pharo Development List" , "Any question about pharo is welcome" Betreff: [Pharo-dev] [ANN] Pharo Consortium Sponsored Development Effort Dear all, I am tremendously happy to announce you that Pharo Consortium will sponsor yet another development effort. In this particular case, it's my honor to carry on such an effort and I will be developing and improving a few things and ideas. All the contract and paperwork has already been done so it's time to start working. Regarding the developments itself, we discussed about these topics: 1) Experiment with a simpler yet more limited OSProcess alternative to execute OS commands. 2) Improving FileSystem in order to better deal with some POSIX stuff like symbolic links, unix file permissions, etc etc. I have already started with 1). OSProcess is super complete and it involves some packages (OSProcess / CommandShell) as well as some VM plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features (like forking the running image) but we would like to focus only in executing OS commands. In addition, OSProcess dates from quite some years ago when many of the current infrastructure features did not exist yet. So the idea is to think a simpler alternative to execute OS commands, using new features such as threaded FFI (for example, for reading async from pipes), pinned objects, etc. We want to use FFI as much as possible rather than VM plugins. From the image side, we are thinking about an API which would look like a builder-like API (FileSystem, XStream, etc). We have been discussing with David Lewis (OSProcess author) as well as with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc in order to agree in a project that would be worth doing (otherwise we would continue using existing tools). And they have all been very kind with me providing positive discussions. I will soon do a survey to measure the most common use cases of OSProcess and related tools. If you have any thought, question, feedback, or whatever, please let us know. Finally, note that I will be doing this project together with another client's project (Quuve) and my life does not have much free time these days...so please be patient!!! Best, -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort
Mariano, I am really happy to see this and I look forword to helping you in any way I can. Dimitris, It is really interesting that you should suggest this. I think it may be a bit off topic for Mariano's initial goals, but Mariano is the driving force behind Fuel, which is the serializer that I use for RemoteTask in OSProcess/CommandShell. This attempts to do much of what you suggest, using Fuel to return the results of processing executed in a forked image (in the unix sense of "forked", i.e. extremely memory efficient). So maybe if I can help Mariano with his project (which of course I plan to do anyway), then he might be able to help me turn RemoteTask into something reliable enough for general purpose use. Another nice connection here is that Eliot's Spur image model will make #forkSqueak (the primitive behind RemoteTask) more efficient in cases where the cooperating images do a lot of processing, because memory changes are more localized in the Spur memory model. In principle it should be possible to run very large object memories in 64-bit Spur, while forking cooperating images that consume very little additional real memory. Dave On Sat, Dec 19, 2015 at 01:33:07PM +, Dimitris Chloupis wrote: > I am very excited for such a project. > > I hope you manage to fix the stdout problem on macos. > > One thing I would like to see is an expansion of the ability of OSProcess > to launch multiple instances of pharo and make them communicate with each > other. Thats a way to have pharo running on multiple cores. Maybe establish > a framework of communication of images that will be based on the existing > design of the fork mechanism in Pharo. > > Python is doing something similar with multiprocessing module which > launches multiple processes of cpython executable and makes them > communication with each other through a similar api to its threading > module. This way python takes advantage of multiple cores. Python threads > like pharo are green threads and pharo like python has a GIL like > mechanism. > > Taking into account that current computers have at least 4 cores, its not a > bad idea to speed up pharo like this at least 400% ;) > > On Sat, Dec 19, 2015 at 3:24 PM Mariano Martinez Peck > wrote: > > > Dear all, > > > > I am tremendously happy to announce you that Pharo Consortium will sponsor > > yet another development effort. In this particular case, it's my honor to > > carry on such an effort and I will be developing and improving a few things > > and ideas. All the contract and paperwork has already been done so it's > > time to start working. > > > > Regarding the developments itself, we discussed about these topics: > > > > 1) Experiment with a simpler yet more limited OSProcess alternative to > > execute OS commands. > > 2) Improving FileSystem in order to better deal with some POSIX stuff like > > symbolic links, unix file permissions, etc etc. > > > > I have already started with 1). OSProcess is super complete and it > > involves some packages (OSProcess / CommandShell) as well as some VM > > plugins (OSProcessPlugin, AIOPlugin). OSProcess provides lots of features > > (like forking the running image) but we would like to focus only in > > executing OS commands. In addition, OSProcess dates from quite some years > > ago when many of the current infrastructure features did not exist yet. > > > > So the idea is to think a simpler alternative to execute OS commands, > > using new features such as threaded FFI (for example, for reading async > > from pipes), pinned objects, etc. We want to use FFI as much as possible > > rather than VM plugins. > > > > From the image side, we are thinking about an API which would look like a > > builder-like API (FileSystem, XStream, etc). > > > > We have been discussing with David Lewis (OSProcess author) as well as > > with Eliot Miranda, Esteban Lorenzano, Damien Pollet, Stephane Ducasse, etc > > in order to agree in a project that would be worth doing (otherwise we > > would continue using existing tools). And they have all been very kind with > > me providing positive discussions. > > > > I will soon do a survey to measure the most common use cases of OSProcess > > and related tools. > > > > If you have any thought, question, feedback, or whatever, please let us > > know. > > > > Finally, note that I will be doing this project together with another > > client's project (Quuve) and my life does not have much free time these > > days...so please be patient!!! > > > > Best, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > >
Re: [Pharo-users] [Question] Inspecting a collection of strings in Pharo 5 -- edit pane for a string?
On Sat, Dec 19, 2015 at 9:24 PM, Tudor Girba wrote: > Hi, > > Strings are supposed to be immutable, and that is why we do not support > editing by default :). > > I do not think this is good... yes, it would be nice if *literal* strings *would* be immutable, but they are not. The tools should not put artificial constraints on the language model. Strings can be changed, so the inspector has to allow that. It is a debugging tool, after all... Marcus
