Re^7: error 1073741819
by BrowserUk (Patriarch) on Aug 20, 2012 at 04:37 UTC
|
Why would Komodo be messed up though?
See Re^7: threads->new falling in a heap. for a few hints. Then go and ask the Komodo people for support.
The difference is in (?-xism: vs (?^: which is what I get.
The sequence (?^: isn't a legal perl regex construct, so any module that was producing that sequence would never work anywhere.
It is really hard see how a well-known and used module like Regexp::Assemble could produce such an error?
What editor do you use or recommend?
I've been using TextPad for about 15 years. It is far from perfect, but it rarely lets me down...
For all I know Komodo may be a brilliant editor, but as I said in the link above, I wouldn't want to base my earning of a crust upon such a complex piece of software. Not only are you subjecting yourself to the risks of the Komodo programmer's work; but also those of the programmers of half a dozen different language runtimes and the interactions between them.
And any editor that requires 11 kernel threads to edit a single file; in addition to the 32 kernel threads is uses just to start up, is just asking for trouble. It is essentially a lottery machine that is bound to screw up randomly.
I'm a strong advocate of threading, but 43 threads, 6 run-times and goodness knows what other technologies all in a single process? There is simply no way to reason about all the possible states that can exist; much less test them all. It is simply numerically impossible.
At the very least, stop running your perl code from within the editor. Run it from the command line. If it screws up then, you at least know the editor isn't the source of the problem.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] [d/l] [select] |
|
|
The sequence (?^: isn't a legal perl regex construct, so any module that was producing that sequence would never work anywhere. Sure it is, 5.14 and up, see Re^7: error 1073741819
| [reply] |
|
|
| [reply] |
|
|
And any editor that requires 11 kernel threads to edit a single file; in addition to the 32 kernel threads is uses just to start up, is just asking for trouble. It is essentially a lottery machine that is bound to screw up randomly.
I'm a strong advocate of threading, but 43 threads, 6 run-times and goodness knows what other technologies all in a single process? There is simply no way to reason about all the possible states that can exist; much less test them all. It is simply numerically impossible
Do you use Firefox or any other Mozilla browsers? You should be complaining about Gecko browser engine, not Komodo which is a pure XUL/HTML app running inside a browser window (I guess this was ActiveState's solution to making a cross platform IDE, let Mozilla deal with the portability problems). My Firefox has 578 kernel handles, 25 threads, 367 User objects right now.
| [reply] [d/l] |
|
|
Do you use Firefox or any other Mozilla browsers?
Not as my main browser, no. I currently have 14 open tabs in Opera and it is running 17 threads. But that is par for the course given the nature of what a browser has to do. Communicate with DNS; many different servers; css; graphics; audio; video; user...
My editor on the other hand has 37 open files and is using 4 threads; 3 of which are total quiescent until I do something.
You should be complaining about Gecko browser engine, not Komodo
First, I'm not really complaining about Komodo, just saying that given its complexity, I am unsurprised if it screws up every now and then. That is the nature of browsers. But if my opera crashes -- not an unheard of occurrence when watching video via the bastard child of software:Adobe Flash -- then it restarts itself, reopening all the tabs to where they were prior to the crash. At worst, I've lost a half completed PM post or similar.
On the other hand, if my editor crashed, I could well loose many hours of unsaved work. And that would be painful.
Yes, my editor has an automatically save every N minutes configuration option, but I have become so trusting of my editor, I rarely enable it.
The bottom line, use tools you trust for your work; be less concerned by the integrity of tools for unimportant stuff.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
Re^7: error 1073741819
by bulk88 (Priest) on Aug 20, 2012 at 15:25 UTC
|
Thank you so much! Why would Komodo be messed up though?
Have you tried to get a C callstack of the crash? Have you run it from Komodo "Run without Debugging"? Have you run it from Komodo with "Debug in separate console" checked or unchecked?
In all likely hood, what is happening is a C stack or Perl stack recursion when you attach a Perl debugger to the perl process, or Komodo tried to "eval" something in the watch window which is caused C stack exhaustion. Komodo when it debugs perl, loads in a pure perl module called "Your Activestate Komodo Folder\lib\support\dbgp\perllib\perl5db.pl" which sets up a TCPIP socket back to the debugger for communications. | [reply] |
Re^7: error 1073741819
by eversuhoshin (Sexton) on Aug 20, 2012 at 04:18 UTC
|
I checked with my laptop and running the regex assembler I get the same expression that you did!!!
I am reinstalling perl and Komodo in my desktop! Thank you so much!
| [reply] |
Re^7: error 1073741819
by Anonymous Monk on Aug 20, 2012 at 04:21 UTC
|
$ perl5.12.2.exe -e " print qr// "
(?-xism:)
$ perl5.14.1.exe -e " print qr// "
(?^:)
| [reply] [d/l] |