[Pharo-dev] [Pharo 7.0-dev] Build #1155: 20243-Temporary-is-not-detected-as-written-only-when-assigned-in-a-nested-assignment
There is a new Pharo build available! The status of the build #1155 was: SUCCESS. The Pull Request #1658 was integrated: "20243-Temporary-is-not-detected-as-written-only-when-assigned-in-a-nested-assignment" Pull request url: https://github.com/pharo-project/pharo/pull/1658 Issue Url: https://pharo.fogbugz.com/f/cases/20243 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1155/
Re: [Pharo-dev] About the infinite debugger
bump > Am 04.07.2018 um 02:28 schrieb Martin McClure : > >> On 07/03/2018 05:02 PM, Martin McClure wrote: >>> On 06/29/2018 07:48 AM, Guillermo Polito wrote: >>> I know that the exception handling/debugging has been modified several >>> times in the latest years (some refactorings, hiding contexts...), we >>> unfortunately don't have tests for it, so I'd like some more pair of >>> eyes on it. Ben, Martin could you take a look? >>> >> Hi Guille, >> I'm just back from vacation last week, and about to go on vacation for >> another week, but I'll see what I can see. >> About the primitive pragmas for context-marking, I think some of those >> were changed for the exception handling fix that Andres and I did a few >> years back, so *could* be involved in this. I'd hate to see regression >> in the exception handling in an attempt to fix this bug. >> > > After a look at at the pull request, I'm quite sure that removing the > prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring > it! The start of execution of exception handlers must be marked in order > for #findNextHandlerContext to work correctly. If these contexts are not > marked, exceptions signaled from inside an exception handler can find > the wrong handler. See the code and comment in #findNextHandlerContext. > > I'm afraid that I cannot immediately help with the debugger problem, > since I don't know the debugger nearly as well as I do the exception > handling code, and I'm going on vacation for a week in 20 minutes. :-) > Perhaps when I get back I can take a look at it if it is still a problem > by then. > > Regards, > -Martin >
[Pharo-dev] Stdio>>#standardIOStreamNamed:forWrite: bug?
Hi Damien, Vincent and Guille, Just a disclaimer: despite having done some work on this, I don't consider myself an expert. If someone else has a better explanation, please jump in. Damien wrote on discord: > is there a notion of standard input/output on windows ? Yes, console applications can use stdio. PharoConsole.exe when run from a command prompt has stdio. (Note that cygwin terminals are different and don't support stdio (since Pharo uses the native windows functions)). > looks like Alistair added the possibility to open files by number, Holger Freyther deserves the credit here. My clumsy git merging left his name out as the author (sorry Holger!). > that's probably what was missing at the time Stdio was introduced I'm not sure that opening files by fd would be useful in this particular case. There are three ways to access files on Windows: file descriptor - posix compatibility FILE* - posix compatibility HANDLE - windows native The VM uses native operations for file i/o on Windows, e.g. Read/WriteConsole() for stdio (including pipe redirection of stdio). Mixing file descriptors and FILE* is possible if you're careful. I don't know how to mix fd / FILE* and HANDLEs. It's probably better to stick with using native windows functions most of the time. We included these functions on Windows since they exist, and there are probably some use cases, but you need to know what you're doing. File class>>stdioHandles calls primitiveFileStdioHandles() which eventually opens the stdio streams (if possible) using the Windows native GetStdHandle() function. > I suspect File needs a nameless variant (I'm not certain how pipes > work in unix but I doubt echo foo | cat ever touches the filesystem) That's my understanding (it doesn't touch the file system). > hmm but the short-term bug is that the TTY logic in Stdio >> > #standardIOStreamNamed:forWrite: fails when all 3 standard streams are > redirected OK, my understanding of what you are saying is that if all 3 io streams are redirected the method incorrectly determines that a console isn't present and so falls back to calling #createStdioFileFor:. More below... > I also don't understand the assumption there Vincent Blondeau added / modified these methods, so he may be able to provide more information. I think the assumption is that if any of the stdio files are connected to a TTY. then it is possible to open all the stdio files. If none are present, then (on Windows) create regular files to act as a substitute. The problem is that it only tests for a TTY, when what we really want is a TTY or a file or a pipe. Assuming I've understood correctly, maybe try modifying (sorry for the loss of formatting, only the last line is changed): File class>>stdioDescriptorIsATTY ^ (0 to: 2) anySatisfy: [ :fdNum | | res | res := self fileDescriptorType: fdNum. res between: 1 and: 3 ] We'd need to rename the method, since it is misleading, but it looks like it better represents the intended use. Cheers, Alistair
[Pharo-dev] [Pharo 7.0-dev] Build #1154: 22292-MCTraitDefinition-should-correctly-support-stateful-traits
There is a new Pharo build available! The status of the build #1154 was: FAILURE. The Pull Request #1667 was integrated: "22292-MCTraitDefinition-should-correctly-support-stateful-traits" Pull request url: https://github.com/pharo-project/pharo/pull/1667 Issue Url: https://pharo.fogbugz.com/f/cases/22292 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1154/
