I downloaded the pre-release built Thursday, July 26, 2012, 13:30 EDT, which had the same filename as the previous version. I get exactly the same crash on Windows XP 32-bit as before.
Doug On Thu, Jul 26, 2012 at 3:13 PM, Ryan Culpepper <r...@cs.utah.edu> wrote: > Doug: Can you test your program again with the release build that just > completed? (Sorry it wasn't available sooner.) > > Ryan > > > On 07/25/2012 02:39 PM, Doug Williams wrote: >> >> And one last post on this. Now it is reliably running. I'm assuming >> once I got a .zo of the offending module actually built, from then on >> I'm okay as long as I don't play around with it. Does that make sense? >> >> And, just to test that, I deleted the compiled directory and the weird >> behavior comes back. I (re-)load it and hit run enough times until I >> get it to start and from then on it starts fine. [Although I'm not >> sure I should actually trust it - but it seems to be running fine >> after that.] >> >> Doug - done with experimenting for the day - Williams >> >> On Wed, Jul 25, 2012 at 12:27 PM, Doug Williams >> <m.douglas.willi...@gmail.com> wrote: >>> >>> And, actually I was premature with the "I have a work around for >>> Windows XP". Sometimes it runs, but usually it dies in weird and >>> wonderful ways - sometimes with a Win32 error, sometimes with a seg >>> fault during gc, sometimes with errors about undefined symbols various >>> places. It's rather amusing to watch - but I assume memory is just >>> being corrupted now instead of always dying the same way. >>> >>> Let me know when there is a version I can try again. >>> >>> Doug >>> >>> On Wed, Jul 25, 2012 at 12:16 PM, Ryan Culpepper <r...@cs.utah.edu> >>> wrote: >>>> >>>> I suspect the problem is caused by commit 8358420f, which changed match >>>> to >>>> load part of its implementation lazily using lazy-require. Part of that >>>> commit was reverted by 949d12e2, but possibly the use of lazy-require >>>> left >>>> in is causing problems in some cases. >>>> >>>> I think it would be best to just fully revert the commit (8358420f) on >>>> the >>>> release branch. >>>> >>>> Ryan >>>> >>>> >>>> >>>> On 07/25/2012 01:56 PM, Doug Williams wrote: >>>>> >>>>> >>>>> It turns out that if I require racket/match explicitly it works. >>>>> Although I shouldn't have to since racket/match is provided by #lang >>>>> racket. So, I have a work around on Windows XP 32-bit. But it would be >>>>> nice to get the problem fixed. >>>>> >>>>> On Wed, Jul 25, 2012 at 11:51 AM, Doug Williams >>>>> <m.douglas.willi...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> I used Create Executable in DrRacket. But, I just tried raco exe --gui >>>>>> main.rkt to create it and get exactly the same error. >>>>>> >>>>>> On Wed, Jul 25, 2012 at 11:46 AM, Sam Tobin-Hochstadt >>>>>> <sa...@ccs.neu.edu> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Is this application generated with 'raco exe'? Or 'Create >>>>>>> Executable' >>>>>>> in DrRacket? >>>>>>> >>>>>>> On Wed, Jul 25, 2012 at 10:31 AM, Doug Williams >>>>>>> <m.douglas.willi...@gmail.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Some more information on the problem. The application runs fine with >>>>>>>> the pre-release on Windows 7 - 64 bit. >>>>>>>> >>>>>>>> The code that is dying on Windows XP 32-bit is: >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> (require racket/runtime-path) >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> ;;; >>>>>>>> (define-runtime-path subject-path "..\\Subjects.txt") >>>>>>>> >>>>>>>> ;;; >>>>>>>> (define (load-subject-encodings) >>>>>>>> (let ((port (open-input-file subject-path #:mode 'text))) >>>>>>>> (set! subject-encodings >>>>>>>> (append >>>>>>>> default-subject-encodings >>>>>>>> (for/list ((line (in-lines port)) >>>>>>>> #:when (regexp-match? >>>>>>>> #px"^\"(.*)\"\\s*\"(.*)\"" >>>>>>>> line)) >>>>>>>> (match line >>>>>>>> ((pregexp "^\"(.*)\"\\s*\"(.*)\"" (list _ subject >>>>>>>> encoding)) >>>>>>>> (list (pregexp (format "^(?i:~a)" subject)) >>>>>>>> encoding)))))) >>>>>>>> (close-input-port port))) >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> (define subject-encodings default-subject-encodings) >>>>>>>> >>>>>>>> (load-subject-encodings) >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> This code loads some data at load time. It does use match, which >>>>>>>> might >>>>>>>> explain the message: >>>>>>>> >>>>>>>> standard-module-name-resolver: collection not found >>>>>>>> collection: "racket/match" >>>>>>>> in collection directories: >>>>>>>> context...: >>>>>>>> standard-module-name-resolver >>>>>>>> #%embedded:g13106:ground-truth-data: [running body] >>>>>>>> #%embedded:g13057:radar-data: [traversing imports] >>>>>>>> #%embedded:g8619:classifier-panel: [traversing imports] >>>>>>>> main: [traversing imports] >>>>>>>> loop >>>>>>>> >>>>>>>> [Exited. Close box or Ctrl-C closes the console.] >>>>>>>> >>>>>>>> I get when I run the compiled version. In DrRacket it dies with the >>>>>>>> unhandled Win 32 exception. >>>>>>>> >>>>>>>> Doug >>>>>>>> >>>>>>>> On Wed, Jul 25, 2012 at 8:39 AM, Doug Williams >>>>>>>> <m.douglas.willi...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> The pre-release 32-bit version still fails for my large >>>>>>>>> applications >>>>>>>>> at work fails to execute in DrRacket - 32-bit Windows XP. I don't >>>>>>>>> have >>>>>>>>> the source or symbol tables loaded so the only message I get from >>>>>>>>> the >>>>>>>>> Visual Studio debugger is attached. This is the same problem I was >>>>>>>>> having with the previous pre-release version a month or so ago. >>>>>>>>> >>>>>>>>> I can create an executable of the application. It fails because it >>>>>>>>> doesn't find racket/match. I'll look into that further. >>>>>>>>> >>>>>>>>> Doug >>>>>>>>> >>>>>>>>> >>>>>>>> _________________________ >>>>>>>> Racket Developers list: >>>>>>>> http://lists.racket-lang.org/dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> sam th >>>>>>> sa...@ccs.neu.edu >>>> >>>> >>>> >>>> > > _________________________ Racket Developers list: http://lists.racket-lang.org/dev
