iexplorer halts on exit when ActiveXObject has been used

Discussion in 'Javascript' started by Simon, Jan 10, 2006.

  1. Simon

    Simon Guest

    Hi,

    I have written an ActiveX object to resize images and upload them to a
    database, this all works fine but when I close internet explorer the
    process iexporer.exe is still running in my task manager and I can not
    launch anything from the desktop (eg. a web shortcut) without firt
    killing this process. The object is launched using JScript with the
    following code:

    var Launcher = new ActiveXObject("LaunchControl");
    Launcher.Domain = document.domain;
    Launcher.LaunchImageUpload();
    Launcher = null;

    Why is the process still hanging around? I think I've covered disposing
    of all resources used in the ActiveX object (which is a C# windows form
    registered for com interop and installed in the GAC).

    Any help would be much appreciated.

    Simon
    Simon, Jan 10, 2006
    #1
    1. Advertising

  2. Simon

    VK Guest

    Simon wrote:
    > I have written an ActiveX object to resize images and upload them to a
    > database, this all works fine but when I close internet explorer the
    > process iexporer.exe is still running in my task manager and I can not
    > launch anything from the desktop (eg. a web shortcut) without firt
    > killing this process.


    An error in your ActiveX control, and based on the description a nasty
    one (with is bad) but somewhere at the top level (which is good :).
    Consult at microsoft.public.dotnet.languages.csharp

    JScript is not to blame.
    VK, Jan 10, 2006
    #2
    1. Advertising

  3. Simon

    Patient Guy Guest

    "Simon" <> wrote in news:1136906978.612458.231050
    @f14g2000cwb.googlegroups.com:

    > Hi,
    >
    > I have written an ActiveX object to resize images and upload them to a
    > database, this all works fine but when I close internet explorer the
    > process iexporer.exe is still running in my task manager and I can not
    > launch anything from the desktop (eg. a web shortcut) without firt
    > killing this process. The object is launched using JScript with the
    > following code:
    >
    > var Launcher = new ActiveXObject("LaunchControl");
    > Launcher.Domain = document.domain;
    > Launcher.LaunchImageUpload();
    > Launcher = null;


    Your problem is setting Launcher to null. You created Launcher with an
    ActiveXObject constructor using the 'new' operator.

    The way to dispose of the object is to use its destructor, which is the
    'delete' operator:

    delete Launcher; // in place of Launcher = null;

    Some might argue to leave well enough alone, and let the garbage
    collection process take care of de-allocating memory and processing
    involving the object.

    But it is probably the careful programmer who tries to match each 'new'
    with a 'delete' somewhere, within the same scope if possible, but at least
    somewhere in code. It's the old malloc/free code-checking problem to
    avoid memory leaks or processes that refuse to go away.

    I cannot explain what happens when the object is set to 'null,' and I
    would love to know just what is happening, for it might explain what you
    are observing.

    > Why is the process still hanging around? I think I've covered disposing
    > of all resources used in the ActiveX object (which is a C# windows form
    > registered for com interop and installed in the GAC).
    >
    > Any help would be much appreciated.
    >
    > Simon
    >
    Patient Guy, Jan 10, 2006
    #3
  4. Simon

    Patient Guy Guest

    Patient Guy <sevisen.adam@gmailDOTHEREcom> wrote in
    news:Xns9747C68954FCAUVAA@207.115.17.102:

    > "Simon" <> wrote in news:1136906978.612458.231050
    > @f14g2000cwb.googlegroups.com:
    >
    >> Hi,
    >>
    >> I have written an ActiveX object to resize images and upload them to
    >> a database, this all works fine but when I close internet explorer
    >> the process iexporer.exe is still running in my task manager and I
    >> can not launch anything from the desktop (eg. a web shortcut) without
    >> firt killing this process. The object is launched using JScript with
    >> the following code:
    >>
    >> var Launcher = new ActiveXObject("LaunchControl");
    >> Launcher.Domain = document.domain;
    >> Launcher.LaunchImageUpload();
    >> Launcher = null;

    >
    > Your problem is setting Launcher to null. You created Launcher with
    > an ActiveXObject constructor using the 'new' operator.
    >
    > The way to dispose of the object is to use its destructor, which is
    > the 'delete' operator:
    >
    > delete Launcher; // in place of Launcher = null;


    I have to follow up to my own post unfortunately, because I am sure I will
    get upbraided by a few hair-splitters for an improper use of terms here.

    I checked with some sources regarding what exactly 'new' and 'delete' are.
    They are simply whatever mechanism the "system" (being a Javascript
    interpreter in this case) uses for allocating and de-allocating memory.
    Although I never said the 'new' operator was a constructor, it does work
    necessarily through a constructor, which as a function initializes the
    allocated memory (I do not imply that initialization must involve the
    setting of values of properties or methods of the object, or even the
    naming of those properties or methods).

    I did say that the 'delete' operator was a destructor, and I believe in
    the most technical way, that is wrong. Again, it is merely the mechanism
    internal to the system for de-allocating memory in the memory management
    system. A destructor is a function which can be used to set values
    (perhaps in global memory? or in other objects) and perhaps prepare an
    object or object property for proper de-allocation, such as calling
    'delete' on objects which themselves are properties of the object soon to
    be 'delete'd.

    There is a high probability now that more will be said, if only because I
    expanded on my self-doubts here.
    Patient Guy, Jan 10, 2006
    #4
  5. Patient Guy wrote:
    > Patient Guy wrote:

    <snip>
    >> The way to dispose of the object is to use its destructor,
    >> which is the 'delete' operator:
    >>
    >> delete Launcher; // in place of Launcher = null;

    >
    > I have to follow up to my own post unfortunately, because
    > I am sure I will get upbraided by a few hair-splitters for
    > an improper use of terms here.


    I don't think we will be splitting hairs here, you are so far off the
    mark that you have posted a fantasy of VKesque proportions.

    <snip>
    > I did say that the 'delete' operator was a destructor, and
    > I believe in the most technical way, that is wrong.


    Yes it is. Given your proposal that - delete - operations should have a
    one-to-one relationship with - new - operations I assume you are
    viewing - delete - as directly (or actively) resulting in the
    destruction of an object created with the - new - operator and assigned
    to an object property or variable. I.E.:-

    var something = new Somethong();

    - and:-

    delete something;

    - would act upon the object resulting from the - new Something() -
    expression. It does not. It acts upon the object in the scope chain on
    which 'something' is a named property. The ECMA 262 algorithm for -
    delete is:-

    <quote cite="ECMA 262, 3rd Ed. section 11.4.1">
    11.4.1 The delete Operator

    The production UnaryExpression : delete UnaryExpression is
    evaluated as follows:

    1. Evaluate UnaryExpression.
    2. If Type(Result(1)) is not Reference, return true.
    3. Call GetBase(Result(1)).
    4. Call GetPropertyName(Result(1)).
    5. Call the [[Delete]] method on Result(3), providing Result(4) as
    the property name to delete.
    6. Return Result(5).
    </quote>

    The UnaryExpression evaluated in the first step (in - delete
    something; - following - var something = new Something();) is the
    unqualified Identifier - something -, which is resolved against the
    scope chain in accordance with ECMA 262 (assume 3rd edition from now on)
    Section 10.1.4, which always produces a Reference type, so step 2 is
    fine. Step 3 retrieves the 'Base' object from that Reference type, which
    is either the global object (if the variable was declared in the global
    scope) or is a Variable object (if it is a function local variable).

    The property named retrieved in step 4 is the string "something", and so
    step 5 calls the internal [[Delete]] method of the global/variable
    object, passing "something" as the name of the property to delete. The
    algorithm for - [[Delete]] is:-

    <quote cite="ECMA 262, 3rd Ed. section 8.6.5">
    8.6.2.5 [[Delete]] (P)

    When the [[Delete]] method of O is called with property name P, the
    following steps are taken:

    1. If O doesn't have a property with name P, return true.
    2. If the property has the DontDelete attribute, return false.
    3. Remove the property with name P from O.
    4. Return true.
    </quote>

    So you might expect that the property of the global/Variable object with
    the name "something" will be removed from the global/Variable object.

    Now the property of the global/Variable object with the name "something"
    had been assigned a value that is a reference to the object created
    with - new Something() - so the act of removing the property from the
    global/variable object will remove that reference from the system. This
    is where memory management does come into the picture. Javascript uses
    automatic garbage collection and when there are no longer any accessible
    references to an object that object becomes eligible from garbage
    collection (at some undeterminable future time). If the "something"
    property of the global/Variable object was removed it would no longer
    refer to the constructed object, and if its value had been the only
    reference to that object then that object becomes available for garbage
    collection.

    However, step 2 in the [[Delete]] algorithm checks to see if the
    property that is to be deleted has the internal DontDelete attribute,
    and if it does is does not act (the property is not removed).

    The "something" property of the global/Variable object was created as a
    result of a variable declaration, subject to sections 10.1.3, 10.2.1 and
    10.2.3 of the specification, where we find:-

    <quote cite="ECMA 262, 3rd Ed. section 10.2.1">
    10.2.1 Global Code
    ....
    Variable instantiation is performed using the global object as the
    variable object and using property attributes { DontDelete }.
    ....
    </quote>

    <quote cite="ECMA 262, 3rd Ed. section 10.2.3">
    10.2.3 Function Code
    ....
    Variable instantiation is performed using the activation object as
    the variable object and using property attributes { DontDelete }.
    ....
    </quote>

    - and see that the DontDelete attribute is set on all declared global
    and function local variables (except those declared within an - eval -
    function call).

    And so given:-

    var something = new Something();

    - doing:-

    delete something;

    - will be ineffective, it will not result in the removal of the property
    of the global/Variable object, and so it will not result in the removal
    of the value of that property that refers to the object constructed
    with - new Something() -, and while the reference to the object remains
    the constructed object cannot be garbage collection, and will continue
    to consume memory. Thus the proposal that - delete - should be used in
    order to free references to objects so that their memory could be
    released during garbage collection is almost the reverse of good advice.

    Indeed, because the "something" property has a value that is a reference
    to an object, the act of assigning a different value to that property
    will result in the removal of the pre-existing reference from the
    system, reliably. And so:-

    something = null;

    - is a better alternative because it will prevent - something - from
    referring to the constructed object.

    <snip>
    > There is a high probability now that more will be said,
    > if only because I expanded on my self-doubts here.


    ;-)

    Richard.
    Richard Cornford, Jan 11, 2006
    #5
  6. Simon

    Simon Guest

    Thanks for all the replies.

    I have to say I don't completely understand the last post but I have
    tried using the 'delete' keyword and combinations of 'delete' and ' =
    null;' to no avail.

    Having had some time to think more about this, it's my impression the
    iexplorer.exe process is blocking for some reason when Internet
    Explorer is closing as I can use the rest of my application fine even
    after opening and closing the ActiveX object. It seems as IE tries to
    close the ActiveX object is not letting go (technical term :)

    The ActiveX code in object looks like this;

    public void LaunchImageUpload()
    {
    using (FormPhotoUpload _FormPhotoUpload = new
    FormPhotoUpload(_Domain))
    {
    _FormPhotoUpload.ShowDialog();
    }
    }

    Because this is a modal dialog can it be keeping a reference to the
    parent window (IE) which is not released?

    I will probably have to follow VK's advice and post on
    microsoft.public.dotnet.languages.csharp to solve that side of things.
    Although I have a test page which will close IE fine and it is just;

    <html>
    <head>
    <script language="javascript">
    var Launcher = new ActiveXObject("LaunchControl");
    Launcher.Domain = "localhost";
    Launcher.LaunchImageUpload();
    </script>
    </head>
    <body>
    </body>
    </html>

    Thanks again for taking the time to help with this.

    Simon
    Simon, Jan 11, 2006
    #6
  7. I must admit, I've been coding in JS for a while now, but didn't
    really understand the difference between:

    -----------------------
    xx = new Object ();
    -----------------------

    and

    -----------------------
    var xx = new Object ();
    -----------------------

    I found your post very informative, thank you!

    Best regards,
    Arnaud
    Arnaud Diederen, Jan 11, 2006
    #7
  8. Simon

    VK Guest

    Patient Guy wrote:
    > If you don't find any use for or of the operator 'delete', why would it be
    > proposed in the language specification?


    Well, actually it was introduced by Netscape to *delete* custom
    properties from objects, one release after they gave the ability to
    *add* custom properties to host objects (originally to window only).
    And it was long before the modern OOP tools ;-)

    So instead of creating a bunch of global vars (especially if you
    couldn't know in advance their exact amount) you extended window:
    window['foo'] = 1; window['bar']=2 etc.

    Now any kid can do var myObject = {'foo':1, 'bar':2}; but Object()
    constructor came only later, plus the *thinking* itself in such terms
    had to be invented and learned yet.

    Nevertheless what is "delete" now, and how does it affect on memory
    management is irrelevant to the history.

    I just see that you're taking JavaScript way too C'ish while it is
    mostly Java'ish. You cannot directly destroy objects because you don't
    have an explicit destructor and you have no real memory access. You can
    only delete references - by using delete operator or by the old "kill
    Kenny" method objReference = null (or even more nasty objReference =
    undefined). The object memory heap by itself remains in any
    circumstances: unnamed and unreferenced, waiting for the garbage truck.

    Also in IE window / document properties implement the unfamous slogan
    "Once in - never out": you can window['foo'] = 1; but you cannot delete
    window.foo

    This way the original purpose of "delete" is lost anyway, so feel free
    to use it wherever it helps. :)
    VK, Jan 11, 2006
    #8
  9. Simon

    Guest

    Patient Guy wrote:
    > Richard Cornford wrote:
    >> Patient Guy wrote:
    >>> Patient Guy wrote:

    >> <snip>
    >>>> The way to dispose of the object is to use its destructor,
    >>>> which is the 'delete' operator:
    >>>>
    >>>> delete Launcher; // in place of Launcher = null;
    >>>
    >>> I have to follow up to my own post unfortunately, because
    >>> I am sure I will get upbraided by a few hair-splitters for
    >>> an improper use of terms here.

    >>
    >> I don't think we will be splitting hairs here, you are so far
    >> off the mark that you have posted a fantasy of VKesque
    >> proportions.
    >>
    >> <snip>
    >>> I did say that the 'delete' operator was a destructor, and
    >>> I believe in the most technical way, that is wrong.

    >>
    >> Yes it is. Given your proposal that - delete - operations should
    >> have a one-to-one relationship with - new - operations I assume
    >> you are viewing - delete - as directly (or actively) resulting
    >> in the destruction of an object created with the - new - operator
    >> and assigned to an object property or variable. I.E.:-

    >
    > Actually not, if you read my post carefully.


    I did read your post carefully, how carefully did you read mine?

    <snip>
    > I said that the 'new' and 'delete' operations were intended
    > to invoke a memory management mechanism in the system whose
    > internal workings are left to the implementor.


    Yes you did, which is what I have paraphrased above. specifically
    relating to - delete - you use the term "invoke", and that implies
    direct (or active) object destruction in the context of what you have
    written.

    > Do these operations ALWAYS----must they always--- involve the
    > use of construction and destruction, or the use of a function
    > that is a constructor and destructor, respectively. One gets
    > into trouble---especially here---if they assert with "epistemic
    > certainty" that all new operations involve constructors and
    > delete operations involve an uncalled-in-code destructor.


    In javascript all functions are capable of being used with the new
    operator and are, in a sense, constructors (that is, they all implement
    the internal [[Construct]] method). Functions that return objects
    cannot effectively be used as a constructor for new objects, but all
    other functions can (including functions that return primitive values).
    And if the operand of the - new - operator is not a function then an
    exception is thrown, so all non-erroring uses of the - new - operator
    will involve a functions (which is effectively a constructor by virtue
    of being a function).

    All operations using - delete - certainly do not involve destructors,
    except as a possible side-effect consequence of the action of the
    delete operator.

    <snip>
    >> var something = new Somethong();
    >>
    >> - and:-
    >>
    >> delete something;
    >>
    >> - would act upon the object resulting from the - new Something() -
    >> expression. It does not. It acts upon the object in the scope
    >> chain on which 'something' is a named property.

    >
    > The var 'something' is a reference to the object created by use
    > of a constructor call Something.
    >
    > Clearly the operation
    >
    > delete something;
    >
    > UNDOES what the 'new' operation


    No, that is not what the delete operator does at all.

    > (you can argue about the details of the
    > implementation) did to create that object.


    There is no question of what the implementation does, what is important
    is what the delete operator does.

    > delete something;
    >
    > says, "take the object that you refer to and de-allocate its
    > memory...no further reference to the object or any of its
    > properties is intended."


    Not in javascript. In javascript - delete - says; resolve the operand
    to a Reference type and remove the named property from the Reference
    type's base object (assuming that the operand did resolve as a
    Reference type and the property is not marked DontDelete).

    > If I said or otherwise implied that properties to the 'delete'd
    > object which themselves are references to other objects and are
    > 'delete'd as part of the delete operation, then that is not the
    > case. However, I don't believe I ever said that.


    You did not say that, it was what you did say, and have repeated, that
    I am correcting.

    > If you are trying to make the case that the object referenced
    > by 'something' is somehow distinct from the object returned
    > by the 'new Something();' call, then please re-iterate this,
    > and with perhaps a very clear demonstration of proof.


    I am not trying to make that case. I am quote happy to assume that
    there have been no modifications to the value of - something -
    in-between the assignment of the reference to the constructed object
    and the application of the - delete - operator upon - something -.



    >> The ECMA 262 algorithm for -
    >> delete is:-
    >>
    >> <quote cite="ECMA 262, 3rd Ed. section 11.4.1">
    >> 11.4.1 The delete Operator
    >>
    >> The production UnaryExpression : delete UnaryExpression is
    >> evaluated as follows:
    >>
    >> 1. Evaluate UnaryExpression.
    >> 2. If Type(Result(1)) is not Reference, return true.
    >> 3. Call GetBase(Result(1)).
    >> 4. Call GetPropertyName(Result(1)).
    >> 5. Call the [[Delete]] method on Result(3), providing Result(4) as
    >> the property name to delete.
    >> 6. Return Result(5).
    >> </quote>
    >>
    >> The UnaryExpression evaluated in the first step (in - delete
    >> something; - following - var something = new Something();) is the
    >> unqualified Identifier - something -, which is resolved against the
    >> scope chain in accordance with ECMA 262 (assume 3rd edition from now on)
    >> Section 10.1.4, which always produces a Reference type, so step 2 is
    >> fine. Step 3 retrieves the 'Base' object from that Reference type, which
    >> is either the global object (if the variable was declared in the global
    >> scope) or is a Variable object (if it is a function local variable).
    >>
    >> The property named retrieved in step 4 is the string "something", and so
    >> step 5 calls the internal [[Delete]] method of the global/variable
    >> object, passing "something" as the name of the property to delete. The
    >> algorithm for - [[Delete]] is:-
    >>
    >> <quote cite="ECMA 262, 3rd Ed. section 8.6.5">
    >> 8.6.2.5 [[Delete]] (P)
    >>
    >> When the [[Delete]] method of O is called with property name P, the
    >> following steps are taken:
    >>
    >> 1. If O doesn't have a property with name P, return true.
    >> 2. If the property has the DontDelete attribute, return false.
    >> 3. Remove the property with name P from O.
    >> 4. Return true.
    >> </quote>
    >>
    >> So you might expect that the property of the global/Variable object
    >> with the name "something" will be removed from the global/Variable
    >> object.

    >
    > No, I don't.


    That was a rhetorical 'you'. Someone reading the algorithms for -
    delete - and the [[Delete]] method of Objects quoted from the
    language's specification, and not thinking about the DontDelet
    attribute, might expect - delete something; - to result in the removal
    of a "something" property from whichever object on the scope chain had
    such a property.

    > I expect the object that is referred to by 'something' to be
    > "removed" (deconstructed, destroyed, whatever).


    And I am informing you that javascript's delete operator does not do
    that, historically and by specification. Having directly quoted the
    applicable algorithms from the specification I was not expecting you to
    still be maintaining your fantasy at this point.

    > I don't believe anywhere in my previous posts did I ever contend
    > that a variable name 'something' is itself destroyed.


    No, if you had maintained that you would have been correct, as that is
    precisely what javascript's delete operator does (subject to the
    DontDelete restriction).

    >> Now the property of the global/Variable object with the name
    >> "something" had been assigned a value that is a reference to
    >> the object created with - new Something() - so the act of
    >> removing the property from the global/variable object will remove
    >> that reference from the system.

    >
    >
    > "...remove that reference...."?
    >
    > Or remove the object referred to?


    No, it will only remove the reference. It is the garbage collectors
    task to identify and remove freed objects.

    >> This is where memory management does come into the picture.
    >> Javascript uses automatic garbage collection and when there
    >> are no longer any accessible references to an object that object
    >> becomes eligible from garbage collection (at some undeterminable
    >> future time). If the "something" property of the global/Variable
    >> object was removed it would no longer refer to the constructed
    >> object, and if its value had been the only reference to that
    >> object then that object becomes available for garbage collection.

    >
    >
    > Yes, and I don't believe I ever contended anything contrary
    > to that view.


    You implied that the - delete - operator would act upon the object
    created with - new Something(); - in a way that resulted in its
    destruction. While the most the delete operator can do is remove
    reference to that object so that it may become eligible for garbage
    collection at some future time.

    >> However, step 2 in the [[Delete]] algorithm checks to see if the
    >> property that is to be deleted has the internal DontDelete
    >> attribute, and if it does is does not act (the property is not
    >> removed).
    >>
    >> The "something" property of the global/Variable object was created
    >> as a result of a variable declaration, subject to sections 10.1.3,
    >> 10.2.1 and 10.2.3 of the specification, where we find:-
    >>
    >> <quote cite="ECMA 262, 3rd Ed. section 10.2.1">
    >> 10.2.1 Global Code
    >> ...
    >> Variable instantiation is performed using the global object as
    >> the variable object and using property attributes { DontDelete }.
    >> ...
    >> </quote>
    >>
    >> <quote cite="ECMA 262, 3rd Ed. section 10.2.3">
    >> 10.2.3 Function Code
    >> ...
    >> Variable instantiation is performed using the activation object as
    >> the variable object and using property attributes { DontDelete }.
    >> ...
    >> </quote>
    >>
    >> - and see that the DontDelete attribute is set on all declared
    >> global and function local variables (except those declared within
    >> an - eval - function call).
    >>
    >> And so given:-
    >>
    >> var something = new Something();
    >>
    >> - doing:-
    >>
    >> delete something;
    >>
    >> - will be ineffective, it will not result in the removal of the
    >> property of the global/Variable object, and so it will not result
    >> in the removal of the value of that property that refers to the
    >> object constructed with - new Something() -, and while the
    >> reference to the object remains the constructed object cannot be
    >> garbage collection, and will continue to consume memory. Thus the
    >> proposal that - delete - should be used in order to free
    >> references to objects so that their memory could be released
    >> during garbage collection is almost the reverse of good advice.

    >
    > Again, you seem to be making the argument that I contended that
    > the name by which to refer to the created object is somehow acted
    > upon the by 'delete' operation.


    I am not saying that you contended it. I am saying that is how delete
    works in javascript.

    <snip>
    > ... . I never made the case that the 'delete' operation acts on
    > the identifier, but rather on what the identifier/variable refers to.


    The delete operator acts upon the object on the scope chain for which
    the Identifier is a named property. It _does_not_ not act upon the
    object referred to by the value of that property.

    >> Indeed, because the "something" property has a value that is a
    >> reference to an object, the act of assigning a different value
    >> to that property will result in the removal of the pre-existing
    >> reference from the system, reliably. And so:-
    >>
    >> something = null;
    >>
    >> - is a better alternative because it will prevent - something -
    >> from referring to the constructed object.

    >
    > You seem to be arguing against what I see to be the CLASSICAL
    > USAGE and PRACTICE of the 'delete' operator.


    What do you consider the "CLASSICAL USAGE" of the delete operator in
    javascript? The language's specification makes it very clear what that
    operator is supposed to do; remove named properties from objects.

    > Exactly in what cases would you find it appropriate to use the
    > operator 'delete'?


    When I wanted to remove a named property from an object (and knew that
    the DontDelete attribute was not applicable to that property). I would
    use the delete operator when I wanted to do what the operator does.

    > If you don't find any use for or of the operator 'delete', why
    > would it be proposed in the language specification?

    <snip>

    Who said I don't have any use for it. I certainly don't use it very
    often, but it is extremely rare that I see any advantage in removing
    named properties from objects.

    Richard.
    , Jan 11, 2006
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rahul T.
    Replies:
    3
    Views:
    8,679
    sundar
    Dec 3, 2004
  2. Replies:
    1
    Views:
    336
    Bruno Desthuilliers
    Mar 19, 2006
  3. Karlo Lozovina
    Replies:
    2
    Views:
    389
    Karlo Lozovina
    Apr 16, 2006
  4. Todd

    python mysteriously halts

    Todd, Jul 7, 2008, in forum: Python
    Replies:
    5
    Views:
    278
    Gabriel Genellina
    Jul 15, 2008
  5. Ricardo Ramalho

    Regexp and string halts ruby

    Ricardo Ramalho, Jan 25, 2007, in forum: Ruby
    Replies:
    7
    Views:
    105
    James Edward Gray II
    Jan 26, 2007
Loading...

Share This Page