June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Monticello / OS deadlock ?

by Thierry Goubier

Hi Dave, Le 03/06/2015 03:15, David T. Lewis a Ã©crit : > Hi Thierry and Jose, > > I am reading this thread with interest and will help if I can. > > I do have one idea that we have not tried before. I have a theory that this may > be an intermittent problem caused by SIGCHLD signals (from the external OS process > when it exits) being missed by the UnixOSProcessAccessor>>grimReaperProcess > that handles them. > > If this is happening, then I may be able to change grimReaperProcess to > work around the problem. > > When you see the OS deadlock condition, are you able tell if your Pharo VM > process has subprocesses in the zombie state (indicating that grimReaperProcess > did not clean them up)? The unix command "ps -axf | less" will let you look > at the process tree and that may give us a clue if this is happening. I found it very easy to reproduce and I do have a zombie children process to the pharo process. Interesting enough, the lock-up happens in a very specific place, a call to git branch, which is a very short command returning just a few characters (where all other commands have longuer outputs). Reducing the frequency of the calls to git branch by a bit of caching reduces the chances of a lock-up. Thanks, Dave > Thanks! > > Dave > > >

June 3, 2015

Timezone offset in Date, why?

by Esteban A. Maringolo

I'm debugging the PostgresV3 driver for GLORP, and among other test failures, there is a kind that particularly bugs me: two identical dates do not match, the reason? The internal "start" of aDate (Timespan) is a DateAndTime, and as such has a timezone offset. Is this conceptually right? Esteban A. Maringolo

June 3, 2015

pillar remove numbering from some headings

by Peter UhnÃ¡k

Hi, is there a way to remove heading numbering for some headings? Basically I'm looking for an equivalent of Latex' \subsection*{...}. Thanks, Peter

June 3, 2015

Re: [Pharo-users] Monticello / OS deadlock ?

by David T. Lewis

On Tue, Jun 02, 2015 at 02:34:49PM +0200, Thierry Goubier wrote: > 2015-06-02 12:14 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: > > > Hi Thierry, > > > > ConfigurationOfOSProcess-ThierryGoubier.38.mcz, which corresponds to > > version 4.6.2. > > > > Ok, then this is the latest. > > > > > > Another workaround that would work for me is to be able to "resume" a > > previous load attempt of a Metacello project. Or a custom "hook" in > > Metacello to save the image after every dependency is successfully loaded. > > > > Yes, this would work. I'll ask again Dave if he has any idea; the bug is > hard to reproduce. Hi Thierry and Jose, I am reading this thread with interest and will help if I can. I do have one idea that we have not tried before. I have a theory that this may be an intermittent problem caused by SIGCHLD signals (from the external OS process when it exits) being missed by the UnixOSProcessAccessor>>grimReaperProcess that handles them. If this is happening, then I may be able to change grimReaperProcess to work around the problem. When you see the OS deadlock condition, are you able tell if your Pharo VM process has subprocesses in the zombie state (indicating that grimReaperProcess did not clean them up)? The unix command "ps -axf | less" will let you look at the process tree and that may give us a clue if this is happening. Thanks! Dave > > Would you mind telling the linux kernel / libc version of your gentoo box? > > Thierry > > > > > > > > 2015-06-02 11:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > >> Hi Jose, > >> > >> yes, I've noticed that as well. It was, at a point, drastic (i.e. almost > >> allways lock-up) on my work development laptop; it now happens far less > >> often (but it does happens to me from time to time). > >> > >> Dave Lewis, the author of OSProcess, fixed one issue which solved most of > >> the lockups I had, but not all of them. The lockup is in the interaction > >> between OSProcess inside Pharo and the external shell command (i.e. it > >> concerns anything which uses OSProcess), and seems like missing a signal. > >> It is also machine and linux version dependent (Ubuntu 14.10 was horrible, > >> 14.04 and 15.04 on the same hardware are far less sensitive), and seems to > >> also depend on the load of the machine itself. > >> > >> By the way, which version of OSProcess you are using? > >> > >> Thierry > >> > >> > >> 2015-06-02 11:10 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: > >> > >>> Hi, > >>> > >>> In one of our projects we are using Pharo4. The image gets built by > >>> gradle, which loads the Metacello project. Sometimes, we see the build > >>> process hangs. It just don't progress. > >>> > >>> When adding local gitfiletree:// dependencies manually through > >>> Monticello after a while Pharo gets frozen. It's not always the same > >>> repository, it's not always the same number of repositories before it hangs. > >>> > >>> I launched the image with strace, and attached gdb to the frozen process. > >>> It turns out It's waiting for a lock that gets never released. > >>> > >>> The environment is a 64b Gentoo Linux with enough of everything > >>> (multiple monitors, multiple cores, enough RAM). > >>> > >>> I hope anybody could point me how to dig deeper into this. > >>> > >>> # gdb > >>> (gdb) attach [pid] > >>> [..] > >>> Reading symbols from /usr/lib32/libbz2.so.1...(no debugging symbols > >>> found)...done. > >>> Loaded symbols for /usr/lib32/libbz2.so.1 > >>> 0x0809d8bb in signalSemaphoreWithIndex () > >>> (gdb) backtrace > >>> #0 0x0809d8bb in signalSemaphoreWithIndex () > >>> #1 0x0810868c in handleSignal () > >>> #2 <signal handler called> > >>> #3 0x0809d8c8 in signalSemaphoreWithIndex () > >>> #4 0x0809f0af in aioPoll () > >>> #5 0xf76f9671 in display_ioRelinquishProcessorForMicroseconds () from > >>> /home/chous/realhome/toolbox/pharo-5.0/pharo-vm/vm-display-X11 > >>> #6 0x080a1887 in ioRelinquishProcessorForMicroseconds () > >>> #7 0x080767fa in primitiveRelinquishProcessor () > >>> #8 0xb6fc838c in ?? () > >>> #9 0xb6fc3700 in ?? () > >>> #10 0xb7952882 in ?? () > >>> #11 0xb6fc3648 in ?? () > >>> (gdb) disassemble > >>> Dump of assembler code for function handleSignal: > >>> 0x081085e0 <+0>: sub $0x9c,%esp > >>> 0x081085e6 <+6>: mov %ebx,0x90(%esp) > >>> 0x081085ed <+13>: mov 0xa0(%esp),%ebx > >>> 0x081085f4 <+20>: mov %esi,0x94(%esp) > >>> 0x081085fb <+27>: mov %edi,0x98(%esp) > >>> 0x08108602 <+34>: movzbl 0x8168420(%ebx),%esi > >>> 0x08108609 <+41>: mov %ebx,%eax > >>> 0x0810860b <+43>: mov %esi,%edx > >>> 0x0810860d <+45>: call 0x81070d0 <forwardSignaltoSemaphoreAt> > >>> 0x08108612 <+50>: call 0x805aae0 <pthread_self@plt> > >>> 0x08108617 <+55>: mov 0x8168598,%edi > >>> 0x0810861d <+61>: cmp %edi,%eax > >>> 0x0810861f <+63>: je 0x8108680 <handleSignal+160> > >>> 0x08108621 <+65>: lea 0x10(%esp),%esi > >>> 0x08108625 <+69>: mov %esi,(%esp) > >>> 0x08108628 <+72>: call 0x805b330 <sigemptyset@plt> > >>> 0x0810862d <+77>: mov %ebx,0x4(%esp) > >>> 0x08108631 <+81>: mov %esi,(%esp) > >>> 0x08108634 <+84>: call 0x805b0c0 <sigaddset@plt> > >>> 0x08108639 <+89>: movl $0x0,0x8(%esp) > >>> 0x08108641 <+97>: mov %esi,0x4(%esp) > >>> 0x08108645 <+101>: movl $0x0,(%esp) > >>> 0x0810864c <+108>: call 0x805ada0 <pthread_sigmask@plt> > >>> 0x08108651 <+113>: mov %ebx,0x4(%esp) > >>> 0x08108655 <+117>: mov %edi,(%esp) > >>> 0x08108658 <+120>: call 0x805b240 <pthread_kill@plt> > >>> 0x0810865d <+125>: mov 0x90(%esp),%ebx > >>> 0x08108664 <+132>: mov 0x94(%esp),%esi > >>> 0x0810866b <+139>: mov 0x98(%esp),%edi > >>> 0x08108672 <+146>: add $0x9c,%esp > >>> 0x08108678 <+152>: ret > >>> 0x08108679 <+153>: lea 0x0(%esi,%eiz,1),%esi > >>> 0x08108680 <+160>: test %esi,%esi > >>> 0x08108682 <+162>: je 0x810865d <handleSignal+125> > >>> 0x08108684 <+164>: mov %esi,(%esp) > >>> 0x08108687 <+167>: call 0x809d8a0 <signalSemaphoreWithIndex> > >>> => 0x0810868c <+172>: jmp 0x810865d <handleSignal+125> > >>> End of assembler dump. > >>> (gdb) up 3 > >>> (gdb) disassemble > >>> Dump of assembler code for function signalSemaphoreWithIndex: > >>> 0x0809d8a0 <+0>: push %esi > >>> 0x0809d8a1 <+1>: xor %eax,%eax > >>> 0x0809d8a3 <+3>: push %ebx > >>> 0x0809d8a4 <+4>: sub $0x24,%esp > >>> 0x0809d8a7 <+7>: mov 0x30(%esp),%esi > >>> 0x0809d8ab <+11>: test %esi,%esi > >>> 0x0809d8ad <+13>: jle 0x809d918 <signalSemaphoreWithIndex+120> > >>> 0x0809d8af <+15>: mov $0x1,%edx > >>> 0x0809d8b4 <+20>: lea 0x0(%esi,%eiz,1),%esi > >>> 0x0809d8b8 <+24>: mfence > >>> 0x0809d8bb <+27>: mov $0x0,%eax > >>> 0x0809d8c0 <+32>: lock cmpxchg %edx,0x8152d80 > >>> => 0x0809d8c8 <+40>: mov %eax,0x1c(%esp) > >>> 0x0809d8cc <+44>: mov 0x1c(%esp),%eax > >>> 0x0809d8d0 <+48>: test %eax,%eax > >>> 0x0809d8d2 <+50>: jne 0x809d8b8 <signalSemaphoreWithIndex+24> > >>> 0x0809d8d4 <+52>: mov 0x8152d84,%edx > >>> 0x0809d8da <+58>: cmp $0x1ff,%edx > >>> 0x0809d8e0 <+64>: lea 0x1(%edx),%ebx > >>> 0x0809d8e3 <+67>: cmove %eax,%ebx > >>> 0x0809d8e6 <+70>: mov 0x8152d88,%eax > >>> 0x0809d8eb <+75>: cmp %ebx,%eax > >>> 0x0809d8ed <+77>: je 0x809d920 <signalSemaphoreWithIndex+128> > >>> 0x0809d8ef <+79>: mov 0x8152d84,%eax > >>> 0x0809d8f4 <+84>: mov %esi,0x8152da0(,%eax,4) > >>> 0x0809d8fb <+91>: mfence > >>> 0x0809d8fe <+94>: mov %ebx,0x8152d84 > >>> 0x0809d904 <+100>: movl $0x0,0x8152d80 > >>> 0x0809d90e <+110>: call 0x807c2c0 <forceInterruptCheck> > >>> 0x0809d913 <+115>: mov $0x1,%eax > >>> 0x0809d918 <+120>: add $0x24,%esp > >>> 0x0809d91b <+123>: pop %ebx > >>> 0x0809d91c <+124>: pop %esi > >>> 0x0809d91d <+125>: ret > >>> 0x0809d91e <+126>: xchg %ax,%ax > >>> 0x0809d920 <+128>: movl $0x810c888,(%esp) > >>> 0x0809d927 <+135>: movl $0x0,0x8152d80 > >>> 0x0809d931 <+145>: call 0x80a3720 <error> > >>> 0x0809d936 <+150>: jmp 0x809d8ef <signalSemaphoreWithIndex+79> > >>> End of assembler dump. > >>> > >>> Meanwhile, strace gets frozen showing this: > >>> [..] > >>> clone(child_stack=0, > >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > >>> child_tidptr=0x7f63665cd9d0) = 3736 > >>> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > >>> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 > >>> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > >>> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 > >>> rt_sigaction(SIGINT, {0x42a8a0, [], SA_RESTORER, 0x7f6365ba3ad0}, > >>> {SIG_DFL, [], SA_RESTORER, 0x7f6365ba3ad0}, 8) = 0 > >>> wait4(-1, 0x7ffc4ef7f7e8, 0, NULL) = ? ERESTARTSYS (To be restarted > >>> if SA_RESTART is set) > >>> --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- > >>> wait4(-1, > >>> > >> > >> > >

June 3, 2015

Re: [Pharo-users] confirm a291430c0aaf69e0add28d1ecd3fb1ced59a71c7

by seb NZOGANG

a291430c0aaf69e0add28d1ecd3fb1ced59a71c7 2015-06-02 18:52 UTC+02:00, pharo-users-request(a)lists.pharo.org <pharo-users-request(a)lists.pharo.org>: > Mailing list removal confirmation notice for mailing list Pharo-users > > We have received a request from 41.202.219.67 for the removal of your > email address, "sebnzogang(a)gmail.com" from the > pharo-users(a)lists.pharo.org mailing list. To confirm that you want to > be removed from this mailing list, simply reply to this message, > keeping the Subject: header intact. Or visit this web page: > > > http://lists.pharo.org/mailman/confirm/pharo-users_lists.pharo.org/a291430c… > > > Or include the following line -- and only the following line -- in a > message to pharo-users-request(a)lists.pharo.org: > > confirm a291430c0aaf69e0add28d1ecd3fb1ced59a71c7 > > Note that simply sending a `reply' to this message should work from > most mail readers, since that usually leaves the Subject: line in the > right form (additional "Re:" text in the Subject: is okay). > > If you do not wish to be removed from this list, please simply > disregard this message. If you think you are being maliciously > removed from the list, or have any other questions, send them to > pharo-users-owner(a)lists.pharo.org. >

June 2, 2015

Re: [Pharo-users] Visualizing a repository tree

by Alexandre Bergel

Interesting visualization! Keep going! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jun 2, 2015, at 10:57 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Tue, Jun 2, 2015 at 3:07 PM, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > Interesting. The dominance tree layout is quite interesting for this use case. > > There were some upward lines at the bottom of the graph for no apparent reason, not sure what was going on there yet, so I'll look into the layout when I have more time. > > Alternatively you could also use Sugiyama, however either due to the choice of heuristics, or some bug it places high priority on last levels which is really bad (since it is no longer at proper hierarchical layers). > > Peter > > > Doru > > On Tue, Jun 2, 2015 at 12:09 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > HI Offray, > > I gave it a quick bash and come up with the following code. It's just a prototype and could be greatly simplified. > > - MCVersionInfo ancestors for whatever reason returned empty array down the line (so its cut off at the end), but I didn't investigate the problem > - edge building and possibly ancestor retrieval could be simplified with builders; I think RTMondrian has methods for it but can't remember exactly (agilevisualization mentioned RTGraphBuilder but that has been removed to my knowledge) > > ~~~~~~~~~~~~~~~ > mc := MCSmalltalkhubRepository allInstances detect: [ :m | m project = 'Roassal2' ]. > > root := mc versionInfoFromFileNamed: mc readableFileNames first. > > family := Set new. > retriever := nil. > retriever := [ :child | > family add: child. > child ancestors do: [ :a | retriever value: a ] > ]. > retriever value: root. > obs := family asGroup. > > v := RTView new. > es := RTEllipse new size: 15; color: Color blue; elementsOn: obs. > v addAll: es. > > edges := RTEdge > buildEdgesFromObjects: obs > from: #yourself > toAll: #ancestors > using: (RTArrowedLine new withShorterDistanceAttachPoint; color: Color red) > scope: es. > v addAll: edges. > > es @ RTDraggable. > es @ (RTLabelled new text: [ :m | m nameWithout: 'Roassal2' ]). > > v @ RTDraggableView. > v @ RTZoomableView. > > RTDominanceTreeLayout new > verticalGap: 30; > horizontalGap: 15; > on: es. > > v open > ~~~~~~~~~~~~~~~~ > > > <2015-06-02_12:04:32.png> > > Cheers, > Peter > â > > On Tue, Jun 2, 2015 at 5:39 AM, Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: > Hi, > > On a closer detail, seems that [1] contains the starting point I'm looking for. I'll keep you posted and of course any other approach will be listened. > > [1] https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010…> > > Cheers, > > Offray > > > On 01/06/15 22:04, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi all, > > I had asked a similar question before with no much advances, but today I made a discovery that can improve the things a lot: how to export timeline data as structured JSON [1] (and of course this open the possibility to work with it on Pharo). Now I would like to graph the data as a tree with forks, merges and dates and authors of commits. I have seen chronia, but seems overkill for this feature (and is integrated with CVS only). > > [1] http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeli… <http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeli…> > > As usual, any pointer on how to get this going will be greatly appreciated and I will give feedback to the community on how to do it. > > Cheers, > > Offray > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

June 2, 2015

Re: [Pharo-users] PUngLite can't query large database

by Paul DeBruicker

Hi Gareth, Sorry for the stupid question but does your query work on a smaller database, one a tenth the size or so? Maybe by using a #haltIf: that checks for memory usage growth will show something interesting. e.g. self haltIf:[Smalltalk vm memoryEnd > 100000000]. "100MB" And then running Smalltalk reportCPUandRAM to get a few text files of what's using the RAM & CPU. Hope this helps Paul riverdusty wrote > Hi > > I've managed to create a large database, with PUnqLite, that is 562.1MB. > I can't seem to query it though. > I've set fetchBufferSize: (1024*1024*1023). > I've set SmalltalkImage current vm extraVMMemory: (1024*1024*1023). > I've played around in the info.plist setting the SqueakMaxHeapSize to > ridiculous things. > But I keep getting either out of memory or PqFetchError (probably > because it can't fit the whole stream into the image?). > This is why I was asking about the JX9 query and running a query like > that to only return to the image with results I want. > Any suggestions on how I can handle this? > > Info.plist: >> > <key> > SqueakMaxHeapSize > </key> >> > <integer> > 1073741824 > </integer> > Pharo: >> Image >> ----- >> *****/Pharo4.0.image >> Pharo4.0 >> Latest update: #40611 >> Unnamed >> >> Operating System/Hardware >> ------------------------- >> Mac OS 1093 intel > > > > Kind Regards > -- > Gareth Cox > IT Manager/Developer > Inspired Org (PTY) Ltd -- View this message in context: http://forum.world.st/PUngLite-can-t-query-large-database-tp4829931p4830028… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 2, 2015

Re: [Pharo-users] sorting repositories in monticello browser

by Peter UhnÃ¡k

On Tue, Jun 2, 2015 at 4:15 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-06-02 15:49 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Hum. Alphabetical order on what? That is, to take your example >>> me/my-project, should it be done on 'me' or on 'my-project'? >>> >> Hm, that's a good question. It should however be the first letter; so if >> there is "Uko/QualityAssistant" I would expect it sorted by "Uko"; >> otherwise there is no much sense in sorting since I can't do binary-ish >> search. >> If it was by the package name, then the name would have to be swapped; >> "QualityAssistant by Uko" or something like that so I can always look at >> the first letter. >> > > Ok. > > >> >> >>> >>> At the moment, repositories ordered by time of addition in your image >>> has a 'known' behavior: your own repositories come last (and to find them, >>> you just have to look last). Alphabetical ordering would make a mess of >>> that. >>> >> Really? Is that something new? >> This is a screenshot from Pharo 4.0; but it's possible that I have broken >> something >> >> The order seems to me at least to be the order in which the repositories >> were added. >> > > Yes, and I can see that you load many repositories, mixing external > software (Roassal) and the things that you seems to be focusing on. > > I guess a nice difference here would be to sort there among repositories > you have the right to write on and the others... In many (all?) cases, you > just want to see the ones you have the ability to save something in (such > as when doing a Monticello package save or copy). > That's an interesting idea. In most cases I do indeed care only about my packages, but not always. Sometimes I need to look at other (Roassal) to see what exactly has changed or to track down some new bug. But proper sorting would group my packages together anyway so I'm not sure of the benefits here. > > >> >> Could your ordering be solved by just having more readable entries (the >>> entries you suggest)? >>> >> I would say that it would improve it regardless of sorting. >> > > Certainly. But I wonder if it wouldn't be enough. A stable ordering allows > you to remember where things are (at the beginning, in the middle, in the > end, etc...). Alphabetical ordering is not stable. > Why would I need to remember it in the first place? If I am working on more than one product I am not going to remember it anyway. However alphabetical order _is_ stable. While not absolutely (if I add an extra package it would move), but you will not remember exact index where it is. If I am looking for Roassal then I automatically look at the bottom half (or second third) because I know the relative position of the letters within the alphabet. Besides with the "fixed" ordering I have to learn every new package where it was again. > > Example: > - old system browser has a stable ordering, which is alphabetical ordering > of base packages, followed by your packages (or the packages you loaded). > - Nautilus has alphabetical ordering of all packages, including yours. > > Now, try to answer for a newbie the following question: > - You just created a new package with a name of your choosing. Where it is > in the system browser? > - Old system browser ... at the end of the first pane on the left. > - Nautilus ... euh... somewhere in the first pane on the left. > I for one would actually expect it to be sorted among the others. But that may be just my personal preference. I mean, I see all the packages sorted, why would I ever expect a new package to be suddenly out of order? This all probably also heavily depends on how much you use it. If you open it rarely you benefit much more from easy-to-understand ordering that I don't need to remember. If I am working with something constantly than the order doesn't matter since I've built a mental map. But we could make an informal strawpoll to see how (much) people's view vary. > You see? Nautilus has many ways of easily finding that package (using the > filter box), but you need to explain them to the newbie before he can use > them. With the old system browser, no need to do so. > Well we don't need to treat the newbie like an idiot either; given it's looks and position the functionality is obvious. But that gives me another idea that would solve my problem - let the Monticello Browser remember my search and give it the same search power (i.e. multiple repositories "repo1|repo2|..") just like Nautilus. Peter > > Thierry > > >> >> Peter >> > >

June 2, 2015

Re: [Pharo-users] SmalltalkHub permission denied

by Hilaire

Le 02/06/2015 17:06, Ben Coman a Ã©crit : > With the Smalltalkhub web interface, searching for 'Cofilair' lists > 'HilaireFernandes/Cofilair' but selecting that says > 'http://smalltalkhub.com/#!/~HilaireFernandes/Cofilair' page does not exist. > > It seems like the repo is missing. It does exist, but it is private. and I can logon from the web interface. But I am forbiden to do diff for example: Diff browser Error: you are forbidden to access "/mc/HilaireFernandes/Cofilair/main/Cofigest- or to download .mcz file. Error: you are forbidden to access "/mc/HilaireFernandes/Cofilair/main/Cofigest-HilaireFernandes.111.mcz" -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

June 2, 2015

Re: [Pharo-users] SmalltalkHub permission denied

by Ben Coman

On Tue, Jun 2, 2015 at 10:27 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Le 02/06/2015 00:58, Ben Coman a Ã©crit : >> On Tue, Jun 2, 2015 at 4:28 AM, Hilaire <hilaire(a)drgeo.eu> wrote: >>> I have permission denied from Monticello when saving a package to >>> SmalltalkHub repo. >>> Do I miss something? >> Can you copy your repo definition (of course minus the password :) >> cheers -ben >> >> > MCSmalltalkhubRepository > owner: 'HilaireFernandes' > project: 'Cofilair' > user: 'HilaireFernandes' > password: '' > Trying that readonly without a user or password also fails. With the Smalltalkhub web interface, searching for 'Cofilair' lists 'HilaireFernandes/Cofilair' but selecting that says 'http://smalltalkhub.com/#!/~HilaireFernandes/Cofilair' page does not exist. It seems like the repo is missing. cheers -ben

June 2, 2015