ActiveState Community Site - Red Hat / Fedora Core - Comments

re: running scripts

ToddW — Tue, 25 Nov 2008 15:18:56 -0800

How are you running the script, though the Komodo debugger, using the "Tools->Run Command"?

Are there any exceptions being recorded in Komodo's log files:
http://community.activestate.com/faq/komodo-file-locations#log_files

Thanks,
Todd

re: mercurial support in Komodo

ToddW — Mon, 24 Nov 2008 12:01:30 -0800

Komodo does *not* provide any mercurial push/pull support as of yet.

I've logged the following bug so this can be tracked:
http://bugs.activestate.com/show_bug.cgi?id=81110

Add yourself to the bug cc-list and you'll be automatically notified of any progress.

Cheers,
Todd

what status of this now? as

slav0nic — Mon, 24 Nov 2008 05:14:47 -0800

what status of this now? as i saw with mercurial i can't push/pull changes

Setting environment variables in the script

troyt — Fri, 14 Nov 2008 10:58:38 -0800

Reposting (paraphrasing) here from an email response in case anyone else is looking at this:

The SetEnv statements have not succeeded in setting those Perl debugging env vars correctly. You can hardwire these statements at the top of your Perl program:

push @INC, '/usr/local/Komodo';
$ENV{PERLDB_OPTS} = 'RemotePort=localhost:9000'
require '/usr/local/Komodo/perl5db.pl';

re: older linux OS

ToddW — Fri, 07 Nov 2008 15:09:09 -0800

Unfortunately I don't believe this can be fixed. Komodo is based upon Mozilla (Firefox) and with the Komodo 5 release, the underlying software has been updated to the recent Mozilla 1.9 (Firefox 3) codebase, which now requires higher versions of Glibc and other libraries:

* GTK+ 2.10 or higher
* GLib 2.12 or higher
* Pango 1.14 or higher
* X.Org 1.0 or higher

You should still be able to use the older Komodo 4 builds, which are based upon Mozilla 1.8 and as such has lower library requirements.

Redhat Linux 8.0

nsizelove0618 — Thu, 06 Nov 2008 10:36:32 -0800

I have Redhat Linux 8.0 and I get the same message. Can this be resolved?

Fixed this yesterday - please try the nightly

troyt — Thu, 23 Oct 2008 17:48:00 -0700

We had been hitting this error in testing too. We think we've got it solved now. Try the most recent nightly build and let us know how it goes:

http://downloads.activestate.com/Komodo/nightly/

Right, that's what I tried

Nocturnal — Thu, 23 Oct 2008 14:00:11 -0700

Right, that's what I tried but it didn't work. Must be some kind of architecture difference between his and my machine. I'm running 64 bit linux and made what appear to be appropriate adjustments but no-go. I'll look around some more.

Thanks,

Sander

Here's a helpful reference

ericp — Thu, 23 Oct 2008 13:55:37 -0700

http://weblog.jamisbuck.org/2006/9/22/inspecting-a-live-ruby-process

I haven't tried it, but Jamis certainly knows his way around Ruby.

The ruby stack trace for

Nocturnal — Thu, 23 Oct 2008 11:38:53 -0700

The ruby stack trace for each thread and each thread's state would be handy for example. Of course if the internals are trashed there's nothing to salvage but there are certainly cases where system calls block and thereby prevent ruby threads from scheduling. In that case ruby's internals are fine and stack traces would be very helpful to find out which line of code blocked. Think reading from pipes retrieved from popen and getting their status for example.

After attaching gdb to such a process I could see the ruby internal stack trace but that doesnt' really tell me which line of my code caused the problem. Apparently it's possible to call ruby functions to find out but so far I haven't been able to make that work. Someone with more ruby skills (such as you guys) should have much better luck with that.

Thanks,

Sander

If the Ruby thread scheduler dies, you need a C debugger

ericp — Thu, 23 Oct 2008 11:12:31 -0700

I'm not sure what a Ruby debugger that could attach to
a broken Ruby interpreter could tell you if the
internals are broken.

Thanks, that will work for

Nocturnal — Wed, 22 Oct 2008 17:07:47 -0700

Thanks, that will work for code that's prepared in that way. The problem is of course that once the thread scheduler goes South there's no guarantee that the debugger thread will actually still respond when the socket connection is made.

It is possible to connect to a running ruby process using gdb but decyphering what's going on inside is problematic. It would be great if your product could handle this task.

No, but a possible workaround

ericp — Wed, 22 Oct 2008 16:16:02 -0700

The Komodo Ruby debugger can't attach to a Ruby process.

However, you could try starting up the debugger at
runtime if you need it -- this way your process doesn't
incur debugger overhead until the debugger starts up.

Here's how, in rough detail:

1. Start another thread in your process that just opens a
port and listens on it.

2. When a connection is made, it can start up a remote
debugging session, following the steps given in the
"Setting a Break in your Ruby Code" in the online Help.

This will let you examine the state of your app, and
you can see all the running threads, and their state.

VisualDiffer

dafi — Wed, 08 Oct 2008 21:42:09 -0700

I've written VisualDiffer.

It isn't yet fully feature but should fit your needs

Any feedback is very appreciated

--
dafi
Enhance KomodoEdit with MoreKomodo

re: movable tabs

ToddW — Wed, 08 Oct 2008 10:51:39 -0700

There is no such functionality provided in Komodo to do this as yet. There has been a feature request to add this:
http://bugs.activestate.com/show_bug.cgi?id=36367
but it is *not* scheduled to be done in the near future.

Note: You can modify the Source Tree XUL overlay in order to move it another panel, it will require some XUL extension knowledge.

Cheers,
Todd