Archived

This forum has been archived. Please start a new discussion on GitHub.

Icicle binary

Hi there!

Is it possible that you not only release the source directories when a new test version of icicle is being announced but also the output directories?
The problem behind that is that the MS C# compiler is free (comes with the .net framework) but (for obvious reasons) provides no chance to compile .sln files (which come with the current icicle preview.

If you would now release the binaries and interfaces (which are probably being outputted by "make-ing" the solution file, one could easily try icicle without VS.net!

regs,

Stephan

Comments

  • Re: Icicle binary
    Originally posted by stephan
    The problem behind that is that the MS C# compiler is free (comes with the .net framework) but (for obvious reasons) provides no chance to compile .sln files (which come with the current icicle preview.

    Hmmm... I wasn't aware of that. We can definitely bundle the slice2cs compiler as a statically-linked binary. I also don't see why we couldn't make Icicle.dll available as a separate download. With those two binaries, you should have everything you need, I would think.

    Thanks for pointing this out -- I'll try the free C# compiler before the next release and make sure that things work with that, if at all possible.

    Cheers,

    Michi.
  • Hi,

    as a working alternative you could also use the open source C# IDE SharpDevelop - see

    http://www.icsharpcode.net/OpenSource/SD/

    It worked very well for me; I was able to import the solution for the icicle main project (All.sln) and to build the ice.dll without any problems. Also building a C# GUI application using ice was no problem. But you have to translate the *.ice files beforehand and put the generated *.cs files in the corresponding *generated* directories, though.

    Give it a try!

    Cheers,

    Wodi
  • Thanks for that, I didn't know about #develop. I'll give this a go and support it, if possible.

    Cheers,

    Michi.
  • Hey!
    Hi,

    as a working alternative you could also use the open source C# IDE SharpDevelop

    I've tried it and it actually works quite nice. However, I have one point remaining about it:
    I didn't find out how to make custom builds. Is this possible in the current version of Sharpdevelop?
    Or do I have to manually compile the .ice files on the command line and just place the generated .cs files into the project?

    regs,

    Stephan
  • Hi,
    playing around with SharpDevelop I have developed a program to view the contents of the IcePack registry. It's not quite ready - exceptions etc. have to be refined - but already usable. Try it out and give som feedback if it of some use.
    I found the 'Admin' interface of the registry quite restricted - mostly by the lack of information about Ice objects manged in the registry and the lack of published relationships between the items in the registry. And by the way - are the methods 'addObject', 'addObjectWithType" and 'removeObject' really 'nonmutating' or am I overlooking something?

    Cheers,

    Wodi
  • Hi!

    That sounds really interesting. Unfortunately I'm not able to test it - though I'd really like to see what it looks like - could you add a screenshot :) ?!

    regs,

    Stephan
  • Hi,

    find attached a screenshot of the main window.

    Cheers,

    Wodi
  • Wow! It looks really cool!

    regs,

    Stephan
  • mes
    mes California
    Hi,
    Originally posted by wodi
    Hi,
    playing around with SharpDevelop I have developed a program to view the contents of the IcePack registry. It's not quite ready - exceptions etc. have to be refined - but already usable. Try it out and give som feedback if it of some use.
    Thanks for the screenshot, it looks great!
    I found the 'Admin' interface of the registry quite restricted - mostly by the lack of information about Ice objects manged in the registry and the lack of published relationships between the items in the registry.
    Note that the next release of Ice will include significant changes to the IcePack deployment facility. The XML descriptor files will be processed locally by the administrative tool (and no longer by the nodes). The tool converts the XML into Slice types when communicating with the Admin object. This means, for example, that you will be able to query the Admin object for a list of deployed applications, get the descriptor of a deployed application, and inspect all of the server descriptors for the application.

    Let us know if you have any suggestions that make it easier to develop GUI-based admin tools.
    And by the way - are the methods 'addObject', 'addObjectWithType" and 'removeObject' really 'nonmutating' or am I overlooking something?
    No, you're not overlooking something, we were. :)

    These operations should not be marked as nonmutating. We will fix them in the next release.

    Thanks,
    - Mark
  • some comments on experiences with icicle alpha 2 during development of the RegistryViewer:

    (i) I had to synchronize - lock(admin) - the access to the registry from different threads, according to comments in this forum that should not be necessary because the clients should be thread-safe. RegistryViewer uses a background thread to periodically get updated information from the Ice-Registry.

    (ii) After some time of running the program - 15 minutes or so - the application suddenly starts to consume memory and finally gets an OutOfMemory exception in IceUtil.Set.Resize (Stacktrace: IceInternal.ConnectionMonitor.Run() Line 123 - IceUtil.Set.Add() Line 164 - IceUtile.Set.Resize() Line 217.

    (iii) I have been able to build the icicle alpha 2 Ice.dll with the .NET Framework 2.0 Beta and the Visual C# 2005 Express Beta and to run the RegitryViewer under Framwork 2.0 without any problems - apart from the ones mentioned under (ii). Only one aspect is important if you try it out - the Visual C# solution and the project for building the Ice.dll cannot be named "Ice" or you will not be able to build because Microsoft already added an item "Properties" to every project and you get the error message that there is already an item 'Properties' in the namespace 'Ice' - so call your solution and project 'icicle' and set the assembly name to 'Ice' in the build options. :mad:
    Otherwise this IDE is a very good alternative to SharpDevelop because it includes a debugger.

    Cheers,

    Wodi
  • I'll let one of my collegues answer point 1.

    On point 2, that's a bug in the set implementation that I fixed for the next release of Icicle. I don't have a patch handy where I am at the moment. But, if you look at the code in Set.cs, you will find an inverted test somewhere in Resize() that results in an infinite loop that ends up exhausing all memory.

    On point 3, the assembly has been renamed to icecs.dll for the final release, so that will fix this problem.

    Cheers,

    Michi.
  • benoit
    benoit Rennes, France
    (i) I had to synchronize - lock(admin) - the access to the registry from different threads, according to comments in this forum that should not be necessary because the clients should be thread-safe. RegistryViewer uses a background thread to periodically get updated information from the Ice-Registry.

    The implementation of the IcePack::Admin interface should be thread safe and it shouldn't be necessary to synchronize remote invocations on the interface. So I'm not sure why you had to add locking. Can you detail where you had to put the synchronization?

    Thanks!

    Benoit.
  • Michi,
    there are some more bugs in the implementaion of set.cs:

    line 125:
    out: array.SetValue(e.value, index++);
    in: array.SetValue(cursor.value, index++);

    line 157:
    out: if(_capacity * _loadFactor >= _count)
    in: if(_capacity * _loadFactor <= _count)

    lines 223,224:
    out: int hash = System.Math.Abs(e.value.GetHashCode()) % _capacity;
    newTable[hash] = new Entry(e.value, newTable[hash]);
    in: int hash = System.Math.Abs(cursor.value.GetHashCode()) % _capacity;
    newTable[hash] = new Entry(cursor.value, newTable[hash]);

    and sme remarks on my point 3: it is not the name of the assembly
    which is the problem with the new VS - in your project space
    there will be an item "root namespace.Properties", and if you don't
    set the root namespace it will default to the name of the project and
    if that is "Ice" you will have a collison on "Ice.Properties". The remedy
    is simple: just set the root namespace of the project to something else.:D


    Benoit,
    I certainly do not have any doubts about the thread-safety of the Admin
    *implementation* (I use the C++ registry and nodes). It may well be the
    C# client side which makes the problems - and that is of course exusable
    being an alpha version. I have attached a small C# program that shows the
    behaviour by calling various methods on the admin interface from 2 threads.
    There are 4 lock() statements and if they are operative you will see the
    expected behaviour. If they are disabled, after some time one of the calls
    will not return and that thread will hang. Maybe you can explain why that happens.

    Cheers,

    Wodi
  • Thanks for the bug report. This is fixed for the 1.0 release.

    Cheers,

    Michi.