- Pharo-users - lists.pharo.org

[ANN] Basic GitHub-API for Pharo

by Torsten Bergmann

Hi, to get warm with Git, GitFileTree and Iceberg last week I was in need of something quick I could implement to try these new tools out. While being on my GitHub webpage I've seen at the bottom a link to "API" and was happily surprised that GitHub could be accessed also with a REST API. So I wrapped a few of these calls within Pharo and now you can also query GitHub infos easily from inside of the image: (GitHub userNamed: 'astares') avatar inspect "Returns the avatar form" (GitHub userNamed: 'pharo-project') isOrganization (GitHubUser named: 'pharo-project') repositories Code could be improved and extended further, possible also be used for accessing/controlling GitHub from Iceberg later. If you want to play with it just load it from Catalog in Pharo 6.0. Code and docu is available on https://github.com/astares/GitHub-API Have fun T.

Sept. 23, 2016

Re: [Pharo-users] Spec: Class pop list code completion

by Peter Uhnak

Something like this? TextInputFieldModel new enableGlobalsCompletion; openWithSpec On Thu, Sep 22, 2016 at 12:04:50PM -0700, Brad Selfridge wrote: > Is there a way in Spec to pop a list widget that contains class names when > entering a partial class name in a test field, (like GTPlayground does)? > > p.s. I do not want to go down the Glamour route. > > > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/Spec-Class-pop-list-code-completion-tp4916672.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Sept. 23, 2016

Strange behavior with software update

by Norbert Hartl

My project I load via filetree so for every package I have a filetree repo assigned. I have a code snippet that changes all the filetree repos to gitfiletree ones. But when I do System->Software update the repositories are back to the filetree ones. Anyone has an idea what could cause this? thanks, Norbert

Sept. 23, 2016

Re: [Pharo-users] Using a Unix filedescriptor in a FileStream?

by Holger Freyther

> On 23 Sep 2016, at 02:44, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hi Holger, Hi! > Currently the events given by this API are only holding a copy of the raw inotify event in rawEvent and a copy of the raw path in rawPath. Further work is required for translating the events into a more platform independent interface, and for supporting OS X and Windows with this API. However, this is already something that could be useful to you. if I see it correctly you start a poll loop (wait 100ms then call epoll wait)? Would you be interested to try to use AioEventHandler with the primitive I proposed? regards holger

Sept. 23, 2016

Re: [Pharo-users] Spec: Class pop list code completion

by Stephan Eggermont

On 22-09-16 21:42, Johan Fabry wrote: > Hi Brad, > > AFAIK there is nothing prebuilt, you will have to roll your own. > You can configure a SelectEntity for it Stephan

Sept. 23, 2016

Re: [Pharo-users] Pharo not running with macOS Sierra

by Yuriy Tymchuk

> On 23 Sep 2016, at 09:01, MartinW <wm(a)fastmail.fm> wrote: > > vivus-ignis wrote >> which image were you using? The "unofficial" VM from the link presents a >> dialog to open a file and once I select an image, it just disappears and >> nothing happens after that. > > The cog_macos32x86_pharo.cog.spur_201609201401.tar.gz works for me, the > cog_macos64x64_pharo.cog.spur_201609201401.tar.gz does not. You need a 64bit image for that one > > > > -- > View this message in context: http://forum.world.st/Pharo-not-running-with-macOS-Sierra-tp4916468p4916700… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Sept. 23, 2016

Re: [Pharo-users] Pharo not running with macOS Sierra

by MartinW

vivus-ignis wrote > which image were you using? The "unofficial" VM from the link presents a > dialog to open a file and once I select an image, it just disappears and > nothing happens after that. The cog_macos32x86_pharo.cog.spur_201609201401.tar.gz works for me, the cog_macos64x64_pharo.cog.spur_201609201401.tar.gz does not. -- View this message in context: http://forum.world.st/Pharo-not-running-with-macOS-Sierra-tp4916468p4916700… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Sept. 23, 2016

Re: [Pharo-users] Using a Unix filedescriptor in a FileStream?

by Ronie Salgado

Hi Holger, Sorry for not noticing this thread before. Some months ago, I did some experiments myself using inotify and epoll, with the UFFI. I was creating a file system monitoring API similar in design to OSWindow. I just did some minor changes for making this usable along with making a configure script. I left all of the code and some scripts for loading the FileSystemMonitor API at: http://smalltalkhub.com/#!/~ronsaldo/OSCalls . For testing the monitoring API, try the following in a playground: monitor := FileSystemMonitor for: '.' do: [ :event | Transcript show: event; cr. ]. If you do this, open a Transcript and you start browsing some methods in Nautilus, you will start receiving some events where Pharo is accessing the .changes file. For the destroying the monitor and stop receiving the events, you can do the following: monitor destroy. Currently the events given by this API are only holding a copy of the raw inotify event in rawEvent and a copy of the raw path in rawPath. Further work is required for translating the events into a more platform independent interface, and for supporting OS X and Windows with this API. However, this is already something that could be useful to you. Best regards, Ronie 2016-09-20 15:26 GMT-03:00 Holger Freyther <holger(a)freyther.de>: > Hi, > > I explored to use the Linux inotify API using UFFI. The > inotify_init/inotify_init1 routine will me a Unix filedescriptor and I > would like to > > a.) monitor it for being readable > b.) read from it with a stream > > > For a.) I have found the AioEventHandler and think I will be able to call > >>#descriptor: directly and then can use it (still figuring out the API, > probably just wait for the >>#changed: call). > > For b.) I thought I could use AttachableFileStream but that required a > "fileId" but not a filedescriptor. Is there a way I can read from my fd > using the standard stream API (otherwise I can try to use UFFI for read) > > > regards > holger >

Sept. 23, 2016

Re: [Pharo-users] Using a Unix filedescriptor in a FileStream?

by Holger Freyther

> On 22 Sep 2016, at 23:33, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi Holger, Hey! > > I just run all OSSubprocess tests and they all worked! (tested in Pharo 5.0). > > I guess I will commit this on the dev branch and hopefully when this is integrated into the VM I can merge that for my next OSSubprocess release. cool and thank you for trying it so quickly. I thought it make sense to mark non files the same as isStdioStream but that triggers a funny case: do { clearerr(file); if (fread(dst, 1, 1, file) == 1) { bytesRead += 1; if (dst[bytesRead-1] == '\n' || dst[bytesRead-1] == '\r') break; } } while (bytesRead <= 0 && ferror(file) && errno == EINTR); which means 0 or 1 char is read with >>#primRead:into:startingAt:count: and in case of inotify the event is lost (partially read and the rest discarded). I will have to start a discussion why primRead should be line buffered at all. Anyway. My good news is that: "an INotify" | arr fileID | self init: 8r00004000. self prim_add_watch: '/tmp' flags: 16r00000100. arr := ByteArray new: 4096. fileID := StandardFileStream new primFdOpen: fd writable: false. StandardFileStream new primRead: fileID into: arr startingAt: 1 count: 4096. arr has read a file notification event.. :)

Sept. 22, 2016

Re: [Pharo-users] Using a Unix filedescriptor in a FileStream?

by Mariano Martinez Peck

Hi Holger, OK, I made a new VM with your PR after I reviewed it. Good news? It works!!! If you want to check OSSubprocess, I am using now the primCreatePipe from OSProcess because that would answer me directly the SQFiles of the pipe. Originally (before ending up doing that), I was trying to make the pipes myself via FFI ( pipe() ) but I came to the problem we discussed earlier (remember the #name:attachTo:writable:). So now I can go back to my original solution. The code is in # *makePipeWithReadBlocking*: and now it looks like this: | pipePointer returnValue fileDescriptors pipe fileIDsArray fileDescriptor1 fileDescriptor2 | pipePointer := ExternalAddress allocate: 8. [ returnValue := self primitivePipe: pipePointer. (returnValue = -1) ifTrue: [ self perror: 'pipe()' ]. fileIDsArray := Array new: 2. fileDescriptor1 := pipePointer nbUInt32AtOffset: 0. fileDescriptor2 := pipePointer nbUInt32AtOffset: 4. fileIDsArray at: 1 put: *(self primitiveFileOpenUseFileDescriptor: fileDescriptor1 writeFlag: false)*. fileIDsArray at: 2 put: *(self primitiveFileOpenUseFileDescriptor: fileDescriptor2 writeFlag: true).* pipe := OSSPipe newWith: fileIDsArray readBlocking: aBoolean. ] ensure:[ pipePointer free. ]. ^ pipe I just run all OSSubprocess tests and they all worked! (tested in Pharo 5.0). I guess I will commit this on the dev branch and hopefully when this is integrated into the VM I can merge that for my next OSSubprocess release. Thank you very much Holger On Thu, Sep 22, 2016 at 12:35 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Sep 22, 2016 at 12:12 PM, Holger Freyther <holger(a)freyther.de> > wrote: > >> >> > On 21 Sep 2016, at 15:09, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > >> > >> > >> > Exactly. I have been wanting this a couple of times while doing >> OSSubprocess. >> >> >> https://github.com/pharo-project/pharo-vm/pull/108. Would be nice if you >> could review it and give it a try. It adds two primitive (one to work on fd >> one to work on FILE). >> >> I probably also want to do: >> >> sqFile->isStdioStream = isatty(fileno(file)) >> >> >> > Yes, exactly. I remember now. And as I said, I also wanted to be able >> to work at fd or FILE* level and I failed. >> >> Could you give the above a try and then I try to get it into the >> Opensmalltalk VM. >> > > Hi Holger, > > I just reviewed the PR and it looks really good. Please, allow me some > time to get updated to the VM compiling instructions and I will give it a > try. Probably, I will be testing it by doing my original (unused now) > #name:attachToCFile:writable: use the new primitive and running the > OSSubprocess tests. Does this make sense to you? > > Thanks a LOT for going deep and fix it! > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com On Thu, Sep 22, 2016 at 12:35 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Thu, Sep 22, 2016 at 12:12 PM, Holger Freyther <holger(a)freyther.de> > wrote: > >> >> > On 21 Sep 2016, at 15:09, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > >> > >> > >> > Exactly. I have been wanting this a couple of times while doing >> OSSubprocess. >> >> >> https://github.com/pharo-project/pharo-vm/pull/108. Would be nice if you >> could review it and give it a try. It adds two primitive (one to work on fd >> one to work on FILE). >> >> I probably also want to do: >> >> sqFile->isStdioStream = isatty(fileno(file)) >> >> >> > Yes, exactly. I remember now. And as I said, I also wanted to be able >> to work at fd or FILE* level and I failed. >> >> Could you give the above a try and then I try to get it into the >> Opensmalltalk VM. >> > > Hi Holger, > > I just reviewed the PR and it looks really good. Please, allow me some > time to get updated to the VM compiling instructions and I will give it a > try. Probably, I will be testing it by doing my original (unused now) > #name:attachToCFile:writable: use the new primitive and running the > OSSubprocess tests. Does this make sense to you? > > Thanks a LOT for going deep and fix it! > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Sept. 22, 2016