xmlvm-users — For current and interested XMLVM users, for public discussions and anouncements.

Re: [xmlvm-users] Error with --target=posix

[Arno P. <ar...@pu...>]

well, here is the deal: The Boehm Garbage Collector we have bundled with 
XMLVM is adapted to MacOS/iOS (although the Boehm GC can run on other 
platforms). You have two options:

1. Use a Mac platform to compile.
2. Remove all source files from the Boehm GC in the generated project
    and compile with -DXMLVM_NO_GC

Ultimately we should bundle the Boehm GC within XMLVM in such a way that 
it can also be used on different platforms. We'll look into that.

Arno


On 1/12/11 1:47 PM, Leo Izen wrote:
> I can't even compile a hello world with posix target. Take a look at this:
>
> [Leo@chessman ~]$ cat Hello.java
> public class Hello {
>      public static void main(String[] args){
>          System.out.println("Hello World!");
>      }
> }
>
> [Leo@chessman ~]$ javac Hello.java
> [Leo@chessman ~]$ java Hello
> Hello World!
> [Leo@chessman ~]$ xmlvm --in=Hello.class --target=posix --out=Hello-out
> [01/12/11 16:43:20.322]  WARNING: Using Hello-out as application name
> [Leo@chessman ~]$ cd Hello-out
> [Leo@chessman Hello-out]$ cd dist/
> [Leo@chessman dist]$ ls
> Makefile
> [Leo@chessman dist]$ make
> mkdir -p build/
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_io_DataInputStream.c -o
> build/obj/java_io_DataInputStream.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_AbstractMap_1.c -o
> build/obj/java_util_AbstractMap_1.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern_Dollar.c -o
> build/obj/java_util_regex_Pattern_Dollar.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_util_MissingFormatWidthException.c -o
> build/obj/java_util_MissingFormatWidthException.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_ArrayList_1.c -o
> build/obj/java_util_ArrayList_1.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_lang_String.c -o
> build/obj/java_lang_String.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_SortedMap.c -o
> build/obj/java_util_SortedMap.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_WeakHashMap_ValueIterator.c
> -o build/obj/java_util_WeakHashMap_ValueIterator.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_StringTokenizer.c -o
> build/obj/java_util_StringTokenizer.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_lang_ProcessBuilder.c -o
> build/obj/java_lang_ProcessBuilder.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_io_ObjectOutput.c -o
> build/obj/java_io_ObjectOutput.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_lang_SecurityException.c -o
> build/obj/java_lang_SecurityException.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_lang_ThreadLocal.c -o
> build/obj/java_lang_ThreadLocal.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_Map_Entry.c -o
> build/obj/java_util_Map_Entry.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_HashSet.c -o
> build/obj/java_util_HashSet.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_util_concurrent_ConcurrentHashMap_WriteThroughEntry.c -o
> build/obj/java_util_concurrent_ConcurrentHashMap_WriteThroughEntry.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_logging_LogManager_5.c -o
> build/obj/java_util_logging_LogManager_5.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern_8.c -o
> build/obj/java_util_regex_Pattern_8.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_lang_Short_ShortCache.c -o
> build/obj/java_lang_Short_ShortCache.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_lang_ProcessEnvironment_StringEnvironment.c -o
> build/obj/java_lang_ProcessEnvironment_StringEnvironment.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_regex_ASCII.c -o
> build/obj/java_util_regex_ASCII.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/native_java_lang_Object.c -o
> build/obj/native_java_lang_Object.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_lang_CharSequence.c -o
> build/obj/java_lang_CharSequence.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_util_Collections_UnmodifiableMap_UnmodifiableEntrySet_UnmodifiableEntry.c
> -o
> build/obj/java_util_Collections_UnmodifiableMap_UnmodifiableEntrySet_UnmodifiableEntry.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_zip_ZipOutputStream.c -o
> build/obj/java_util_zip_ZipOutputStream.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_spi_LocaleNameProvider.c -o
> build/obj/java_util_spi_LocaleNameProvider.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/mark_rts.c -o build/obj/mark_rts.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_util_Collections_UnmodifiableCollection_1.c -o
> build/obj/java_util_Collections_UnmodifiableCollection_1.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_logging_LogManager_2.c -o
> build/obj/java_util_logging_LogManager_2.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/native_java_io_FileInputStream.c -o
> build/obj/native_java_io_FileInputStream.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_util_UnknownFormatFlagsException.c -o
> build/obj/java_util_UnknownFormatFlagsException.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/native_java_io_ObjectOutputStream.c
> -o build/obj/native_java_io_ObjectOutputStream.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern.c -o
> build/obj/java_util_regex_Pattern.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/native_java_lang_reflect_Constructor.c -o
> build/obj/native_java_lang_reflect_Constructor.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_net_FileNameMap.c -o
> build/obj/java_net_FileNameMap.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_lang_Terminator.c -o
> build/obj/java_lang_Terminator.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/pthread_stop_world.c -o
> build/obj/pthread_stop_world.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_Set.c -o
> build/obj/java_util_Set.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern_GroupHead.c
> -o build/obj/java_util_regex_Pattern_GroupHead.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_io_InvalidClassException.c -o
> build/obj/java_io_InvalidClassException.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_HashMap_KeyIterator.c -o
> build/obj/java_util_HashMap_KeyIterator.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/native_java_lang_ClassLoader_NativeLibrary.c -o
> build/obj/native_java_lang_ClassLoader_NativeLibrary.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/blacklst.c -o build/obj/blacklst.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_AbstractList_ListItr.c -o
> build/obj/java_util_AbstractList_ListItr.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_net_NetworkInterface_1subIFs.c
> -o build/obj/java_net_NetworkInterface_1subIFs.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_net_Inet6Address.c -o
> build/obj/java_net_Inet6Address.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/new_hblk.c -o build/obj/new_hblk.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_lang_annotation_AnnotationFormatError.c -o
> build/obj/java_lang_annotation_AnnotationFormatError.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_io_FilePermissionCollection.c -o
> build/obj/java_io_FilePermissionCollection.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_XMLUtils.c -o
> build/obj/java_util_XMLUtils.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/xmlvm-class-list.c -o
> build/obj/xmlvm-class-list.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_ResourceBundle_Control_1.c
> -o build/obj/java_util_ResourceBundle_Control_1.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_AbstractMap_SimpleEntry.c
> -o build/obj/java_util_AbstractMap_SimpleEntry.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/os_dep.c -o build/obj/os_dep.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_util_concurrent_locks_ReentrantLock_Sync.c -o
> build/obj/java_util_concurrent_locks_ReentrantLock_Sync.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_io_ObjectInputStream_Caches.c -o
> build/obj/java_io_ObjectInputStream_Caches.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_io_FileDescriptor_1.c -o
> build/obj/java_io_FileDescriptor_1.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/native_java_lang_ProcessEnvironment.c
> -o build/obj/native_java_lang_ProcessEnvironment.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_lang_SecurityManager_2.c -o
> build/obj/java_lang_SecurityManager_2.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_Properties.c -o
> build/obj/java_util_Properties.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_util_Collections_CheckedCollection.c -o
> build/obj/java_util_Collections_CheckedCollection.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_Random.c -o
> build/obj/java_util_Random.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_logging_Logger.c -o
> build/obj/java_util_logging_Logger.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c
> ../src/java_util_Collections_UnmodifiableList_1.c -o
> build/obj/java_util_Collections_UnmodifiableList_1.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern_Loop.c -o
> build/obj/java_util_regex_Pattern_Loop.o
> mkdir -p build/obj/
> gcc -w -std=c99 -I../src -c ../src/finalize.c -o build/obj/finalize.o
> In file included from ../src/gc_pmark.h:45:0,
>                   from ../src/finalize.c:17:
> ../src/gc_priv.h:2196:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
> ‘__attribute__’ before ‘GC_jmp_buf’
> make: *** [build/obj/finalize.o] Error 1
> [Leo@chessman dist]$
>
> Is there a way to fix this? Thanx
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] Error with --target=posix

[Leo I. <leo...@gm...>]

I can't even compile a hello world with posix target. Take a look at this:

[Leo@chessman ~]$ cat Hello.java
public class Hello {
    public static void main(String[] args){
        System.out.println("Hello World!");
    }
}

[Leo@chessman ~]$ javac Hello.java
[Leo@chessman ~]$ java Hello
Hello World!
[Leo@chessman ~]$ xmlvm --in=Hello.class --target=posix --out=Hello-out
[01/12/11 16:43:20.322]  WARNING: Using Hello-out as application name
[Leo@chessman ~]$ cd Hello-out
[Leo@chessman Hello-out]$ cd dist/
[Leo@chessman dist]$ ls
Makefile
[Leo@chessman dist]$ make
mkdir -p build/
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_io_DataInputStream.c -o
build/obj/java_io_DataInputStream.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_AbstractMap_1.c -o
build/obj/java_util_AbstractMap_1.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern_Dollar.c -o
build/obj/java_util_regex_Pattern_Dollar.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_MissingFormatWidthException.c
-o build/obj/java_util_MissingFormatWidthException.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_ArrayList_1.c -o
build/obj/java_util_ArrayList_1.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_lang_String.c -o
build/obj/java_lang_String.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_SortedMap.c -o
build/obj/java_util_SortedMap.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_WeakHashMap_ValueIterator.c -o
build/obj/java_util_WeakHashMap_ValueIterator.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_StringTokenizer.c -o
build/obj/java_util_StringTokenizer.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_lang_ProcessBuilder.c -o
build/obj/java_lang_ProcessBuilder.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_io_ObjectOutput.c -o
build/obj/java_io_ObjectOutput.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_lang_SecurityException.c -o
build/obj/java_lang_SecurityException.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_lang_ThreadLocal.c -o
build/obj/java_lang_ThreadLocal.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_Map_Entry.c -o
build/obj/java_util_Map_Entry.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_HashSet.c -o
build/obj/java_util_HashSet.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c
../src/java_util_concurrent_ConcurrentHashMap_WriteThroughEntry.c -o
build/obj/java_util_concurrent_ConcurrentHashMap_WriteThroughEntry.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_logging_LogManager_5.c -o
build/obj/java_util_logging_LogManager_5.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern_8.c -o
build/obj/java_util_regex_Pattern_8.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_lang_Short_ShortCache.c -o
build/obj/java_lang_Short_ShortCache.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c
../src/java_lang_ProcessEnvironment_StringEnvironment.c -o
build/obj/java_lang_ProcessEnvironment_StringEnvironment.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_regex_ASCII.c -o
build/obj/java_util_regex_ASCII.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/native_java_lang_Object.c -o
build/obj/native_java_lang_Object.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_lang_CharSequence.c -o
build/obj/java_lang_CharSequence.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c
../src/java_util_Collections_UnmodifiableMap_UnmodifiableEntrySet_UnmodifiableEntry.c
-o
build/obj/java_util_Collections_UnmodifiableMap_UnmodifiableEntrySet_UnmodifiableEntry.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_zip_ZipOutputStream.c -o
build/obj/java_util_zip_ZipOutputStream.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_spi_LocaleNameProvider.c -o
build/obj/java_util_spi_LocaleNameProvider.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/mark_rts.c -o build/obj/mark_rts.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c
../src/java_util_Collections_UnmodifiableCollection_1.c -o
build/obj/java_util_Collections_UnmodifiableCollection_1.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_logging_LogManager_2.c -o
build/obj/java_util_logging_LogManager_2.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/native_java_io_FileInputStream.c -o
build/obj/native_java_io_FileInputStream.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_UnknownFormatFlagsException.c
-o build/obj/java_util_UnknownFormatFlagsException.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/native_java_io_ObjectOutputStream.c -o
build/obj/native_java_io_ObjectOutputStream.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern.c -o
build/obj/java_util_regex_Pattern.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/native_java_lang_reflect_Constructor.c -o
build/obj/native_java_lang_reflect_Constructor.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_net_FileNameMap.c -o
build/obj/java_net_FileNameMap.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_lang_Terminator.c -o
build/obj/java_lang_Terminator.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/pthread_stop_world.c -o
build/obj/pthread_stop_world.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_Set.c -o
build/obj/java_util_Set.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern_GroupHead.c -o
build/obj/java_util_regex_Pattern_GroupHead.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_io_InvalidClassException.c -o
build/obj/java_io_InvalidClassException.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_HashMap_KeyIterator.c -o
build/obj/java_util_HashMap_KeyIterator.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c
../src/native_java_lang_ClassLoader_NativeLibrary.c -o
build/obj/native_java_lang_ClassLoader_NativeLibrary.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/blacklst.c -o build/obj/blacklst.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_AbstractList_ListItr.c -o
build/obj/java_util_AbstractList_ListItr.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_net_NetworkInterface_1subIFs.c -o
build/obj/java_net_NetworkInterface_1subIFs.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_net_Inet6Address.c -o
build/obj/java_net_Inet6Address.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/new_hblk.c -o build/obj/new_hblk.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c
../src/java_lang_annotation_AnnotationFormatError.c -o
build/obj/java_lang_annotation_AnnotationFormatError.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_io_FilePermissionCollection.c -o
build/obj/java_io_FilePermissionCollection.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_XMLUtils.c -o
build/obj/java_util_XMLUtils.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/xmlvm-class-list.c -o
build/obj/xmlvm-class-list.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_ResourceBundle_Control_1.c -o
build/obj/java_util_ResourceBundle_Control_1.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_AbstractMap_SimpleEntry.c -o
build/obj/java_util_AbstractMap_SimpleEntry.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/os_dep.c -o build/obj/os_dep.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c
../src/java_util_concurrent_locks_ReentrantLock_Sync.c -o
build/obj/java_util_concurrent_locks_ReentrantLock_Sync.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_io_ObjectInputStream_Caches.c -o
build/obj/java_io_ObjectInputStream_Caches.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_io_FileDescriptor_1.c -o
build/obj/java_io_FileDescriptor_1.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/native_java_lang_ProcessEnvironment.c -o
build/obj/native_java_lang_ProcessEnvironment.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_lang_SecurityManager_2.c -o
build/obj/java_lang_SecurityManager_2.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_Properties.c -o
build/obj/java_util_Properties.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_Collections_CheckedCollection.c
-o build/obj/java_util_Collections_CheckedCollection.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_Random.c -o
build/obj/java_util_Random.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_logging_Logger.c -o
build/obj/java_util_logging_Logger.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c
../src/java_util_Collections_UnmodifiableList_1.c -o
build/obj/java_util_Collections_UnmodifiableList_1.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/java_util_regex_Pattern_Loop.c -o
build/obj/java_util_regex_Pattern_Loop.o
mkdir -p build/obj/
gcc -w -std=c99 -I../src -c ../src/finalize.c -o build/obj/finalize.o
In file included from ../src/gc_pmark.h:45:0,
                 from ../src/finalize.c:17:
../src/gc_priv.h:2196:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘GC_jmp_buf’
make: *** [build/obj/finalize.o] Error 1
[Leo@chessman dist]$

Is there a way to fix this? Thanx

Re: [xmlvm-users] Adding new committers

[Hansi R. <su...@su...>]

> Now binary file changes, I don't think I can argue with. They're probably
> not optimized in subversion. I will have to take your word that they are
> handled well in Mercurial/GIT, but I would be interested in seeing how.
>
i really (really really) dislike svn, but you can totally argue with this:
http://en.wikipedia.org/wiki/Apache_Subversion#Features
"Native support for binary files, with space-efficient binary-diff storage."

h,-

Re: [xmlvm-users] Adding new committers

[Paul P. <bay...@gm...>]

Hi Panayotis,

Actually subversion does not copy the entire directory for a branch.  It
simply makes a link to a specific tree/revision.  It is very inexpensive &
should never take more than a split second.
I've been using subversion for not quite 5 years, so maybe there was an
initial version for which this was not true?  Or perhaps this was the case
for CVS?

Also, switching branches is very quick assuming they are common, even
without many internet resources.  It is not like switching to a project with
nothing in common.  E.g. if I had trunk checked out for a large code base, I
can branch in a split second & switch to the new branch in very little time
(a few seconds). This is because they are the same files & nothing needs to
be rechecked out. Subversion will check the hidden ".svn" files for the
revision numbers, and if up to date, it moves on.

Dropping & merging is very simple as well, even if not from the same branch.
E.g. I have a local copy of XMLVM & I merge official XMLVM changes into it.
At my work, we generally have 10+ branches at any time, and everyone easily
merges into our development branch with no trouble.

Now binary file changes, I don't think I can argue with. They're probably
not optimized in subversion. I will have to take your word that they are
handled well in Mercurial/GIT, but I would be interested in seeing how.

I would encourage you to give subversion another chance.  I've had a great
experience with it, and I'm surprised to hear your troubles. Perhaps you
were dealing with a poorly managed repository. I'm being somewhat
hypocritical though, since I can't say I have time to investigate
Mercurial/GIT right now, but I'll keep it in mind.

Paul

On Mon, Jan 10, 2011 at 5:32 PM, Joshua Melcon <xm...@me...> wrote:

> Hi all,
>
> I was recently part of a SCM discussion.  In comparing distributed vs
> traditional source control we have basically come down to understanding that
> you can do exactly the same things with each.  The only difference is
> whether their command line clients make it easy or not.  Distributed SCMs
> seem to focus on making merges easier, traditional focus on carefully
> tracking what goes in to branches.  Distributed seem to spend more time on
> their merge tools, so they seem to merge better..
>
> Regards,
>
> -- Joshua Melcon
>
>
>
> On Mon, Jan 10, 2011 at 3:08 PM, Panayotis Katsaloulis <
> pan...@pa...> wrote:
>
>>
>> On Jan 11, 2011, at 12:48 AM, Paul Poley wrote:
>>
>> > You can do the same thing with subversion.  It's quite easy to make
>> branches & merge with it as well.  I'm not familiar with Mercurial/GIT, but
>> I'm assuming it's just a matter of who's familiar with what.  I'm not
>> directing this at you.  Rather, you could say this about me & Mercurial/GIT,
>> but to steal a rather famous quote:
>> > "You always fear what you don't understand"
>> >
>> > Yes, you can do automatic merging with subversion too, but that misses
>> the point.  Each merge described is a purposeful human decision or we would
>> forget about the branches.  If we think that's too much trouble or too
>> complicated, we don't have to do branching or tagging, but I'm trying to
>> keep quality code separated.  Just because someone wrote some code doesn't
>> mean it's worthy of trunk (myself included).
>> >
>> > So to reiterate, my thoughts are just discussion.  Please feel free to
>> give input or critique.  If you have ideas/comments on Mercurial/GIT, please
>> do share.
>>
>>
>> I am just talking after my own experiences.
>> I've used SVN for a long time and I was too reluctant to move on to
>> mercurial. But there were real advantages on using mercurial instead of SVN.
>>
>> What SVN actually does with branches is to copy the whole directory
>> structure over and over again. To drop a branch or merge two branches was
>> (in my experience) a nightmare, especially if 3-way merge was required (i.e.
>> changes were performed on the same block of code). Moreover, other resources
>> like binaries or files moving around were implemented by a non-optimized
>> way; not to mention the time and internet requirements in the case someone
>> wants to go from one version to another. Even worse, moving from one branch
>> to another was practically moving from one project to another with nothing
>> in common.
>> All these problems made the whole procedure slow, bulky and not really
>> user friendly.
>>
>> Distributed versioning systems have proved to solve these problems in an
>> elegant manner. I've chosen mercurial, but this doesn't matter - any one is
>> good.
>> I can only say that when I went to mercurial, I couldn't go back. I've
>> actually used a lot mercurial during the last months with XMLVM. I've
>> created monster patches, when at the same time official XMLVM tree moved
>> along, and resolved all merges with success. I am convinced that, without
>> the help of mercurial this continuous merging and developing would not have
>> been possible.
>>
>> ------------------------------------------------------------------------------
>> Gaining the trust of online customers is vital for the success of any
>> company
>> that requires sensitive data to be transmitted over the Web.   Learn how
>> to
>> best implement a security strategy that keeps consumers' information
>> secure
>> and instills the confidence they need to proceed with transactions.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] Adding new committers

[Joshua M. <xm...@me...>]

Hi all,

I was recently part of a SCM discussion.  In comparing distributed vs
traditional source control we have basically come down to understanding that
you can do exactly the same things with each.  The only difference is
whether their command line clients make it easy or not.  Distributed SCMs
seem to focus on making merges easier, traditional focus on carefully
tracking what goes in to branches.  Distributed seem to spend more time on
their merge tools, so they seem to merge better..

Regards,

-- Joshua Melcon


On Mon, Jan 10, 2011 at 3:08 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On Jan 11, 2011, at 12:48 AM, Paul Poley wrote:
>
> > You can do the same thing with subversion.  It's quite easy to make
> branches & merge with it as well.  I'm not familiar with Mercurial/GIT, but
> I'm assuming it's just a matter of who's familiar with what.  I'm not
> directing this at you.  Rather, you could say this about me & Mercurial/GIT,
> but to steal a rather famous quote:
> > "You always fear what you don't understand"
> >
> > Yes, you can do automatic merging with subversion too, but that misses
> the point.  Each merge described is a purposeful human decision or we would
> forget about the branches.  If we think that's too much trouble or too
> complicated, we don't have to do branching or tagging, but I'm trying to
> keep quality code separated.  Just because someone wrote some code doesn't
> mean it's worthy of trunk (myself included).
> >
> > So to reiterate, my thoughts are just discussion.  Please feel free to
> give input or critique.  If you have ideas/comments on Mercurial/GIT, please
> do share.
>
>
> I am just talking after my own experiences.
> I've used SVN for a long time and I was too reluctant to move on to
> mercurial. But there were real advantages on using mercurial instead of SVN.
>
> What SVN actually does with branches is to copy the whole directory
> structure over and over again. To drop a branch or merge two branches was
> (in my experience) a nightmare, especially if 3-way merge was required (i.e.
> changes were performed on the same block of code). Moreover, other resources
> like binaries or files moving around were implemented by a non-optimized
> way; not to mention the time and internet requirements in the case someone
> wants to go from one version to another. Even worse, moving from one branch
> to another was practically moving from one project to another with nothing
> in common.
> All these problems made the whole procedure slow, bulky and not really user
> friendly.
>
> Distributed versioning systems have proved to solve these problems in an
> elegant manner. I've chosen mercurial, but this doesn't matter - any one is
> good.
> I can only say that when I went to mercurial, I couldn't go back. I've
> actually used a lot mercurial during the last months with XMLVM. I've
> created monster patches, when at the same time official XMLVM tree moved
> along, and resolved all merges with success. I am convinced that, without
> the help of mercurial this continuous merging and developing would not have
> been possible.
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] --target=posix

[Arno P. <ar...@pu...>]

that would be possible. Right now we have red-listed certain classes 
from J2SE that don't make sense under iOS (such as AWT or Swing). 
However, I can imagine of having a flexible way of defining which 
classes to red-list based on the target. In order to support AWT on a 
different platform you would have to implement the corresponding native 
methods that pertain to AWT.

I added a few slides to our master slide set that give some details to 
the C backend: xmlvm/doc/slides

Arno


On 1/10/11 2:33 PM, Leo Izen wrote:
> I know most of the xmlvm hype is about the iphone, but I'm quite
> interested in seeing AWT ported to Xlib or GTK+. Would this be possible?
> Thanx!
>
> On Mon, Jan 10, 2011 at 12:27 PM, Arno Puder <ar...@pu...
> <mailto:ar...@pu...>> wrote:
>
>
>     Guys,
>
>     a few days ago I posted a reply giving two examples on how to use the C
>     backend. We have since integrated the C backend better into the XMLVM
>     processing pipeline. Here is how to do the two examples I mentioned
>     earlier using the latest version of XMLVM:
>
>     java -Xmx700m -jar dist/xmlvm.jar --target=posix \
>        --in=bin/org/xmlvm/test/ReflectionTest.class \
>        --out=ReflectionTest
>     cd ReflectionTest/dist
>     make
>     ./build/ReflectionTest
>
>     Note that there is a --target=posix now. This target will generate a
>     self-contained project as well as a Makefile to make compiling easier.
>     For the posix target we also now include the garbage collector. This
>     means that you can cross-compile a Java program to any standard Posix
>     platform!
>
>     Here is how to compile iFireworks with the simplified XMLVM pipeline:
>
>     cd demo/iphone/ifireworks
>     ant
>     cd -
>     java -Xmx700m -jar dist/xmlvm.jar --target=iphone-c \
>        --app-name=iFireworks \
>        --resource=demo/iphone/ifireworks/res/ \
>        --in=demo/iphone/ifireworks/build/classes/ \
>        --out=ifireworks
>     open ifireworks/dist/iFireworks.xcodeproj
>
>     What is still missing is the implementation of native methods as well as
>     the Cocoa wrapper for iOS applications. But things are moving along
>     nicely.
>
>     Arno
>
>
>     ------------------------------------------------------------------------------
>     Gaining the trust of online customers is vital for the success of
>     any company
>     that requires sensitive data to be transmitted over the Web.   Learn
>     how to
>     best implement a security strategy that keeps consumers' information
>     secure
>     and instills the confidence they need to proceed with transactions.
>     http://p.sf.net/sfu/oracle-sfdevnl
>     _______________________________________________
>     xmlvm-users mailing list
>     xml...@li...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Adding new committers

[Panayotis K. <pan...@pa...>]

On Jan 11, 2011, at 12:48 AM, Paul Poley wrote:

> You can do the same thing with subversion.  It's quite easy to make branches & merge with it as well.  I'm not familiar with Mercurial/GIT, but I'm assuming it's just a matter of who's familiar with what.  I'm not directing this at you.  Rather, you could say this about me & Mercurial/GIT, but to steal a rather famous quote:
> "You always fear what you don't understand"
> 
> Yes, you can do automatic merging with subversion too, but that misses the point.  Each merge described is a purposeful human decision or we would forget about the branches.  If we think that's too much trouble or too complicated, we don't have to do branching or tagging, but I'm trying to keep quality code separated.  Just because someone wrote some code doesn't mean it's worthy of trunk (myself included).
> 
> So to reiterate, my thoughts are just discussion.  Please feel free to give input or critique.  If you have ideas/comments on Mercurial/GIT, please do share.


I am just talking after my own experiences.
I've used SVN for a long time and I was too reluctant to move on to mercurial. But there were real advantages on using mercurial instead of SVN.

What SVN actually does with branches is to copy the whole directory structure over and over again. To drop a branch or merge two branches was (in my experience) a nightmare, especially if 3-way merge was required (i.e. changes were performed on the same block of code). Moreover, other resources like binaries or files moving around were implemented by a non-optimized way; not to mention the time and internet requirements in the case someone wants to go from one version to another. Even worse, moving from one branch to another was practically moving from one project to another with nothing in common.
All these problems made the whole procedure slow, bulky and not really user friendly. 

Distributed versioning systems have proved to solve these problems in an elegant manner. I've chosen mercurial, but this doesn't matter - any one is good.
I can only say that when I went to mercurial, I couldn't go back. I've actually used a lot mercurial during the last months with XMLVM. I've created monster patches, when at the same time official XMLVM tree moved along, and resolved all merges with success. I am convinced that, without the help of mercurial this continuous merging and developing would not have been possible.

Re: [xmlvm-users] Adding new committers

[Paul P. <bay...@gm...>]

You can do the same thing with subversion.  It's quite easy to make branches
& merge with it as well.  I'm not familiar with Mercurial/GIT, but I'm
assuming it's just a matter of who's familiar with what.  I'm not directing
this at you.  Rather, you could say this about me & Mercurial/GIT, but to
steal a rather famous quote:
"You always fear what you don't understand"

Yes, you can do automatic merging with subversion too, but that misses the
point.  Each merge described is a purposeful human decision or we would
forget about the branches.  If we think that's too much trouble or too
complicated, we don't have to do branching or tagging, but I'm trying to
keep quality code separated.  Just because someone wrote some code doesn't
mean it's worthy of trunk (myself included).

So to reiterate, my thoughts are just discussion.  Please feel free to give
input or critique.  If you have ideas/comments on Mercurial/GIT, please do
share.

Thanks!
Paul

On Mon, Jan 10, 2011 at 4:16 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On Jan 10, 2011, at 10:36 PM, Paul Poley wrote:
>
> > I have to admit I like you three being sorts of gatekeepers to the
> repository to make sure not just anything is making it in.  But I also
> understand having only 3 people becomes more difficult as the project grows.
>
> I believe the best solution for this problem with a more flexible
> versioning system than SVN.
> It's not the first time I vote in favor of Mercurial/GIT which are able to
> make and handle branches and merging much easier and most of the time in an
> automatic manner.
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] --target=posix

[Leo I. <leo...@gm...>]

Not Everyone uses a mac >.<

On Mon, Jan 10, 2011 at 5:38 PM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On Jan 11, 2011, at 12:33 AM, Leo Izen wrote:
>
> > I know most of the xmlvm hype is about the iphone, but I'm quite
> interested in seeing AWT ported to Xlib or GTK+. Would this be possible?
> Thanx!
>
> I am also thinking of more interesting solutions: use Java for Cocoa, or
> even use Java for applications submitted to the Mac App Store :)
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] --target=posix

[Panayotis K. <pan...@pa...>]

On Jan 11, 2011, at 12:33 AM, Leo Izen wrote:

> I know most of the xmlvm hype is about the iphone, but I'm quite interested in seeing AWT ported to Xlib or GTK+. Would this be possible? Thanx!

I am also thinking of more interesting solutions: use Java for Cocoa, or even use Java for applications submitted to the Mac App Store :)

Re: [xmlvm-users] --target=posix

[Leo I. <leo...@gm...>]

I know most of the xmlvm hype is about the iphone, but I'm quite interested
in seeing AWT ported to Xlib or GTK+. Would this be possible? Thanx!

On Mon, Jan 10, 2011 at 12:27 PM, Arno Puder <ar...@pu...> wrote:

>
> Guys,
>
> a few days ago I posted a reply giving two examples on how to use the C
> backend. We have since integrated the C backend better into the XMLVM
> processing pipeline. Here is how to do the two examples I mentioned
> earlier using the latest version of XMLVM:
>
> java -Xmx700m -jar dist/xmlvm.jar --target=posix \
>   --in=bin/org/xmlvm/test/ReflectionTest.class \
>   --out=ReflectionTest
> cd ReflectionTest/dist
> make
> ./build/ReflectionTest
>
> Note that there is a --target=posix now. This target will generate a
> self-contained project as well as a Makefile to make compiling easier.
> For the posix target we also now include the garbage collector. This
> means that you can cross-compile a Java program to any standard Posix
> platform!
>
> Here is how to compile iFireworks with the simplified XMLVM pipeline:
>
> cd demo/iphone/ifireworks
> ant
> cd -
> java -Xmx700m -jar dist/xmlvm.jar --target=iphone-c \
>   --app-name=iFireworks \
>   --resource=demo/iphone/ifireworks/res/ \
>   --in=demo/iphone/ifireworks/build/classes/ \
>   --out=ifireworks
> open ifireworks/dist/iFireworks.xcodeproj
>
> What is still missing is the implementation of native methods as well as
> the Cocoa wrapper for iOS applications. But things are moving along nicely.
>
> Arno
>
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Adding new committers

[Panayotis K. <pan...@pa...>]

On Jan 10, 2011, at 10:36 PM, Paul Poley wrote:

> I have to admit I like you three being sorts of gatekeepers to the repository to make sure not just anything is making it in.  But I also understand having only 3 people becomes more difficult as the project grows.

I believe the best solution for this problem with a more flexible versioning system than SVN.
It's not the first time I vote in favor of Mercurial/GIT which are able to make and handle branches and merging much easier and most of the time in an automatic manner.  

Re: [xmlvm-users] Adding new committers

[Paul P. <bay...@gm...>]

I have to admit I like you three being sorts of gatekeepers to the
repository to make sure not just anything is making it in.  But I also
understand having only 3 people becomes more difficult as the project grows.

That being said, I have a few thoughts, and they are just that, so anyone
feel free to reject, improve or approve the following.  I think this is a
good discussion to be had.

What if you begin allowing certain committers, but only you 3 have commit
access to trunk.  I.e. we begin using branches & tags.
Exhibit #1:
http://en.wikipedia.org/wiki/Apache_Subversion#Branching_and_tagging

If we started today, we would immediately make tag 1.0.0 from trunk.
Since most will not be committing to trunk, there's a couple of options for
branches, but here's one.  There is a primary development branch into which
all completed work will be done.  Any committer can put their work there,
but should only commit finished milestones, not works in progress.

More advanced developers can create a personal branch, in which works in
progress may be committed.  E.g. I may make
"xmlvm/branches/ppoley/synchronizedSupport".
When finished, they will merge their work into the development branch with a
comment such as:
"Support for synchronization
merge -r5260:5283
http://xmlvm.svn.sourceforge.net/svnroot/xmlvm/branches/ppoley/synchronizedSupport
"

Any unwanted commits will be reverse merged out of the branch.

Since only the 3 will have access to trunk, they will merge a set of stable
changes into trunk from time to time & then immediately make a new tag to
mark the milestone.  This still puts somewhat of a bottle neck on the 3, but
a much smaller one since this doesn't have to be done for each change.

One downside is not immediately being able to immediately see original
committer when looking at trunk, but if the merge into trunk is done in the
same manner as above including the merge command, you can go to that branch
& see who did what.

In this way, the development branch does not change.  If for some reason we
felt the development branch had been corrupted by changes that didn't make
it to trunk, we could delete the branch & recreate it from trunk at the same
location.

Thanks,
Paul

On Sun, Jan 9, 2011 at 6:03 PM, Arno Puder <ar...@pu...> wrote:

>
> Guys,
>
> we had some internal discussions regarding the future of XMLVM from a
> project management perspective. Right now there are three core team
> members (Sascha, Wolfgang, and myself) who are the only ones to have
> commit rights. Contributors have to submit their patches to an online
> review system where the core team members review the patch and if
> accepted, commit it to the Subversion repository by mentioning the name
> of the contributor in the commit log. We have laid out the guidelines
> concerning coding conventions that can be found at:
> http://xmlvm.org/contribute/
>
> We believe that in order to grow as a project, we need to be more
> flexible with regards to this process. In the long run the current model
> does not scale with regards to the amount of work.
>
> We propose to introduce a new role within the XMLVM project: the role of
> a committer. A committer, just like the core team members, has commit
> rights to the Subversion repository. The core team can offer a
> contributor the role of committer if the contributor has proven
> him-/herself over a period of time to deliver high-quality patches that
> follow XMLVM coding conventions. A committer typically is responsible
> for a certain module within XMLVM. Within that module, the committer can
> make changes according to his or her discretion. If a change is
> necessary outside that module, the modification should be done by
> consulting the core team. As a good practice, major changes should be
> discussed on the mailing list anyways. If a committer repeatedly
> violates XMLVM coding conventions, the core team member can rescind the
> commit rights.
>
> We would like to put these guidelines up for discussion on the mailing
> list. We believe that it will help grow XMLVM as well as acknowledge and
> recognize significant contributions by some developers.
>
> The XMLVM Core Team
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

[xmlvm-users] --target=posix

[Arno P. <ar...@pu...>]

Guys,

a few days ago I posted a reply giving two examples on how to use the C 
backend. We have since integrated the C backend better into the XMLVM 
processing pipeline. Here is how to do the two examples I mentioned 
earlier using the latest version of XMLVM:

java -Xmx700m -jar dist/xmlvm.jar --target=posix \
   --in=bin/org/xmlvm/test/ReflectionTest.class \
   --out=ReflectionTest
cd ReflectionTest/dist
make
./build/ReflectionTest

Note that there is a --target=posix now. This target will generate a 
self-contained project as well as a Makefile to make compiling easier. 
For the posix target we also now include the garbage collector. This 
means that you can cross-compile a Java program to any standard Posix 
platform!

Here is how to compile iFireworks with the simplified XMLVM pipeline:

cd demo/iphone/ifireworks
ant
cd -
java -Xmx700m -jar dist/xmlvm.jar --target=iphone-c \
   --app-name=iFireworks \
   --resource=demo/iphone/ifireworks/res/ \
   --in=demo/iphone/ifireworks/build/classes/ \
   --out=ifireworks
open ifireworks/dist/iFireworks.xcodeproj

What is still missing is the implementation of native methods as well as 
the Cocoa wrapper for iOS applications. But things are moving along nicely.

Arno

Re: [xmlvm-users] Publishing XMLVM applications

[Paul P. <bay...@gm...>]

I am happy to see your apology.  Please keep in mind this is a friendly
group, and I have not seen anyone here with ill intentions.  I want to say
that I am quite appreciative of everything the XMLVM group has provided, and
the support & encouragement they exhibit.  They have also been very open in
listening to the community & discussing major changes, even though they
should have the authority to make a change or not without discussion so
since it is their creation.

As a third party, it seems more appropriate that I am the one to say your
attack was unprovoked, and I hope we can act courteous amongst each other.
But again, I am happy to see you have already recognized that.

Thanks,
Paul

On Mon, Jan 10, 2011 at 3:03 AM, Hansi Raber <su...@su...> wrote:

> p.s. sorry if i replied in my "pissed off" voice, i'm rather grumpy in the
> morning and that's not
> the best time to write an email.
> i do genuinely mean what i said, please imagine it was written in a nicer
> tone.
>
> sincere apologies...
> best, h,-
>
>
>
> On Mon, Jan 10, 2011 at 9:06 AM, Hansi Raber <su...@su...> wrote:
>
>> hey!
>>
>> There is a bit of a mentality out there that Open Source just springs
>>> into being and free for anyone to use.
>>
>> quite an allegation, and as far as it concerns me you couldn't be further
>> from the truth.
>>
>>
>>> A GPL-type license is just a
>>> little reminder also to give back.
>>>
>> well, this "little reminder" might (as i wrote earlier) cause some rather
>> nasty legal issues (even if no one sues).
>>
>> also --- give _what_ back? maybe xmlvm is not perfect yet, but it's quite
>> usable and it'll continue to improve. for the average xmlvm user it
>> shouldn't
>> be necessary to even look at the source.
>>
>>
>> you make it sound like i suggested  you give out software under the wtfpl,
>> all i was saying is that one small portion of xmlvm better be excluded
>> from the (l)gpl
>> (the template files and compat libs) to circumvent some weird
>> practicalities.
>>
>>
>>
>>
>> either way, it seems that using lgpl was a decission not a discussion. in
>> that sense
>> good luck ...
>>
>>
>>
>>
>>
>>
>> best, hansi.
>>
>
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] Publishing XMLVM applications

[Hansi R. <su...@su...>]

p.s. sorry if i replied in my "pissed off" voice, i'm rather grumpy in the
morning and that's not
the best time to write an email.
i do genuinely mean what i said, please imagine it was written in a nicer
tone.

sincere apologies...
best, h,-


On Mon, Jan 10, 2011 at 9:06 AM, Hansi Raber <su...@su...> wrote:

> hey!
>
> There is a bit of a mentality out there that Open Source just springs
>> into being and free for anyone to use.
>
> quite an allegation, and as far as it concerns me you couldn't be further
> from the truth.
>
>
>> A GPL-type license is just a
>> little reminder also to give back.
>>
> well, this "little reminder" might (as i wrote earlier) cause some rather
> nasty legal issues (even if no one sues).
>
> also --- give _what_ back? maybe xmlvm is not perfect yet, but it's quite
> usable and it'll continue to improve. for the average xmlvm user it
> shouldn't
> be necessary to even look at the source.
>
>
> you make it sound like i suggested  you give out software under the wtfpl,
> all i was saying is that one small portion of xmlvm better be excluded from
> the (l)gpl
> (the template files and compat libs) to circumvent some weird
> practicalities.
>
>
>
>
> either way, it seems that using lgpl was a decission not a discussion. in
> that sense
> good luck ...
>
>
>
>
>
>
> best, hansi.
>

Re: [xmlvm-users] Publishing XMLVM applications

[Hansi R. <su...@su...>]

hey!

There is a bit of a mentality out there that Open Source just springs
> into being and free for anyone to use.

quite an allegation, and as far as it concerns me you couldn't be further
from the truth.


> A GPL-type license is just a
> little reminder also to give back.
>
well, this "little reminder" might (as i wrote earlier) cause some rather
nasty legal issues (even if no one sues).

also --- give _what_ back? maybe xmlvm is not perfect yet, but it's quite
usable and it'll continue to improve. for the average xmlvm user it
shouldn't
be necessary to even look at the source.


you make it sound like i suggested  you give out software under the wtfpl,
all i was saying is that one small portion of xmlvm better be excluded from
the (l)gpl
(the template files and compat libs) to circumvent some weird
practicalities.




either way, it seems that using lgpl was a decission not a discussion. in
that sense
good luck ...






best, hansi.

[xmlvm-users] Adding new committers

[Arno P. <ar...@pu...>]

Guys,

we had some internal discussions regarding the future of XMLVM from a 
project management perspective. Right now there are three core team 
members (Sascha, Wolfgang, and myself) who are the only ones to have 
commit rights. Contributors have to submit their patches to an online 
review system where the core team members review the patch and if 
accepted, commit it to the Subversion repository by mentioning the name 
of the contributor in the commit log. We have laid out the guidelines 
concerning coding conventions that can be found at: 
http://xmlvm.org/contribute/

We believe that in order to grow as a project, we need to be more 
flexible with regards to this process. In the long run the current model 
does not scale with regards to the amount of work.

We propose to introduce a new role within the XMLVM project: the role of 
a committer. A committer, just like the core team members, has commit 
rights to the Subversion repository. The core team can offer a 
contributor the role of committer if the contributor has proven 
him-/herself over a period of time to deliver high-quality patches that 
follow XMLVM coding conventions. A committer typically is responsible 
for a certain module within XMLVM. Within that module, the committer can 
make changes according to his or her discretion. If a change is 
necessary outside that module, the modification should be done by 
consulting the core team. As a good practice, major changes should be 
discussed on the mailing list anyways. If a committer repeatedly 
violates XMLVM coding conventions, the core team member can rescind the 
commit rights.

We would like to put these guidelines up for discussion on the mailing 
list. We believe that it will help grow XMLVM as well as acknowledge and 
recognize significant contributions by some developers.

The XMLVM Core Team

Re: [xmlvm-users] Publishing XMLVM applications

[Arno P. <ar...@pu...>]

any license imposes rules that you will have to follow. One aspect that 
I personally like about the GNU type licenses is that it imposes a 
"community aspect": if you make a modification, you need to contribute 
this back to the community. BSD does not impose this. You might argue 
that it is in a developers best interest to contribute modifications 
back in order to stay in sync with the main trunk. This is certainly 
true for small patches/fixes, but I would also like to impose this for 
new modules that the developer might decide to withhold for competitive 
reasons.

There is a bit of a mentality out there that Open Source just springs 
into being and free for anyone to use. A GPL-type license is just a 
little reminder also to give back.

Well, I suggest to tackle the problems as they arise. As Sascha pointed 
out, we do want you to be able to use XMLVM for your proprietary 
products. Just don't forget that someone has to do all the work and 
perhaps think of way to participate in the community.

Arno


On 1/9/11 3:15 PM, Hansi Raber wrote:
> hey!
>
>     The message that we, the XMLVM team, want to give to you is that we
>     would never do such a thing, if it would be possible, which it
>     isn't.The LPGL should, with small modifications, be in accordance
>     with AppStore rules.
>
> right, and i'm more than amazed by how open your are about this.
>
> i don't mean to be a jerk about this or doing pointless discussion that
> go nowhere, but i think that picking a
> license that expresses your intentions best is key, otherwise any
> promise made now might be hard to live up to.
>
> this seems to be what amount of work the lgpl brings with it if one
> _actually_ wants to be compliant:
> http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2010-August/026708.html
> sure, ffmpeg is known for it's hall of shame and their overal policy
> towards license violations.
>
> however, if i understand correctly the freedoms that come with the lgpl
> apply to
> anyone, not just the devs. anyone must have the ability to exchange the
> xmlvm portion of an app with a newer version.
> in some cases this is completely impossible because xmlvm mixes together
> different code bases into single files which
> makes it impossible to just exchange the xmlvm part later on.
>
> imho the best would be to use a bsd license for the output modules (by
> that i mean the template files and
> runtime libaries). everything else could even be gpl without problems.
> as i wrote a month or so ago, a license exception like the one bison has
> for certain source files would also
> be just fine.
>
>
>
> best, hansi.
>
>
>     So the bottom line is that XMLVM developers should not worry that
>     their apps might get pulled because of licensing issues.
>
>     // Sascha
>
>
>     On Sun, Jan 9, 2011 at 10:46 PM, Hansi Raber <su...@su...
>     <mailto:su...@su...>> wrote:
>
>
>         On Sun, Jan 9, 2011 at 8:58 PM, Tor Lillqvist <tm...@ik...
>         <mailto:tm...@ik...>> wrote:
>
>             Wasn't the problem with VLC (the withdrawal of which from
>             the App
>             Store seems to have caused this discussion) that some of the
>             copyright
>             holders were opposed to it being offered on the App Store?
>
>         afaik that was a completely different issue,
>         some important parts of vlc are licensed under the gpl (e.g. the
>         h264 decoder).
>         the problem was that the appstore imposes restrictions stronger
>         than the
>         gpl allows, thus apple decided to pull the app.
>
>
>
>         anyways, here's a good read:
>         http://huyzing.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/
>
>
>
>
>         best, hansi.
>
>
>         ------------------------------------------------------------------------------
>         Gaining the trust of online customers is vital for the success
>         of any company
>         that requires sensitive data to be transmitted over the Web.
>         Learn how to
>         best implement a security strategy that keeps consumers'
>         information secure
>         and instills the confidence they need to proceed with transactions.
>         http://p.sf.net/sfu/oracle-sfdevnl
>         _______________________________________________
>         xmlvm-users mailing list
>         xml...@li...
>         <mailto:xml...@li...>
>         https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Publishing XMLVM applications

[Hansi R. <su...@su...>]

hey!

The message that we, the XMLVM team, want to give to you is that we would
> never do such a thing, if it would be possible, which it isn't.The LPGL
> should, with small modifications, be in accordance with AppStore rules.

right, and i'm more than amazed by how open your are about this.

i don't mean to be a jerk about this or doing pointless discussion that go
nowhere, but i think that picking a
license that expresses your intentions best is key, otherwise any promise
made now might be hard to live up to.

this seems to be what amount of work the lgpl brings with it if one
_actually_ wants to be compliant:
http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2010-August/026708.html
sure, ffmpeg is known for it's hall of shame and their overal policy towards
license violations.

however, if i understand correctly the freedoms that come with the lgpl
apply to
anyone, not just the devs. anyone must have the ability to exchange the
xmlvm portion of an app with a newer version.
in some cases this is completely impossible because xmlvm mixes together
different code bases into single files which
makes it impossible to just exchange the xmlvm part later on.

imho the best would be to use a bsd license for the output modules (by that
i mean the template files and
runtime libaries). everything else could even be gpl without problems.
as i wrote a month or so ago, a license exception like the one bison has for
certain source files would also
be just fine.



best, hansi.


So the bottom line is that XMLVM developers should not worry that their apps
> might get pulled because of licensing issues.
>
> // Sascha
>
>
> On Sun, Jan 9, 2011 at 10:46 PM, Hansi Raber <su...@su...> wrote:
>
>>
>> On Sun, Jan 9, 2011 at 8:58 PM, Tor Lillqvist <tm...@ik...> wrote:
>>
>>> Wasn't the problem with VLC (the withdrawal of which from the App
>>> Store seems to have caused this discussion) that some of the copyright
>>> holders were opposed to it being offered on the App Store?
>>>
>> afaik that was a completely different issue,
>> some important parts of vlc are licensed under the gpl (e.g. the h264
>> decoder).
>> the problem was that the appstore imposes restrictions stronger than the
>> gpl allows, thus apple decided to pull the app.
>>
>>
>>
>> anyways, here's a good read:
>>
>> http://huyzing.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/
>>
>>
>>
>>
>> best, hansi.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Gaining the trust of online customers is vital for the success of any
>> company
>> that requires sensitive data to be transmitted over the Web.   Learn how
>> to
>> best implement a security strategy that keeps consumers' information
>> secure
>> and instills the confidence they need to proceed with transactions.
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> xmlvm-users mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>>
>>
>

Re: [xmlvm-users] Publishing XMLVM applications

[Sascha H. <sa...@xm...>]

Hansi,

while the dispute on VLC was indeed about the GPL, it wasn't Apple who
decided to pull the app, but as Tor mentioned, one of the Copyright holders
of the VLC project. As far as I know, this person decided to file a
complaint to Apple that the app could not be distributed in the AppStore due
to GPL restrictions. Apple responded to this complaint by pulling the app.

The message that we, the XMLVM team, want to give to you is that we would
never do such a thing, if it would be possible, which it isn't.The LPGL
should, with small modifications, be in accordance with AppStore rules.

So the bottom line is that XMLVM developers should not worry that their apps
might get pulled because of licensing issues.

// Sascha


On Sun, Jan 9, 2011 at 10:46 PM, Hansi Raber <su...@su...> wrote:

>
> On Sun, Jan 9, 2011 at 8:58 PM, Tor Lillqvist <tm...@ik...> wrote:
>
>> Wasn't the problem with VLC (the withdrawal of which from the App
>> Store seems to have caused this discussion) that some of the copyright
>> holders were opposed to it being offered on the App Store?
>>
> afaik that was a completely different issue,
> some important parts of vlc are licensed under the gpl (e.g. the h264
> decoder).
> the problem was that the appstore imposes restrictions stronger than the
> gpl allows, thus apple decided to pull the app.
>
>
>
> anyways, here's a good read:
>
> http://huyzing.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/
>
>
>
>
> best, hansi.
>
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] Publishing XMLVM applications

[Hansi R. <su...@su...>]

On Sun, Jan 9, 2011 at 8:58 PM, Tor Lillqvist <tm...@ik...> wrote:

> Wasn't the problem with VLC (the withdrawal of which from the App
> Store seems to have caused this discussion) that some of the copyright
> holders were opposed to it being offered on the App Store?
>
afaik that was a completely different issue,
some important parts of vlc are licensed under the gpl (e.g. the h264
decoder).
the problem was that the appstore imposes restrictions stronger than the
gpl allows, thus apple decided to pull the app.



anyways, here's a good read:
http://huyzing.com/2009/08/24/compatibility-between-the-iphone-app-store-and-the-lgpl/




best, hansi.

Re: [xmlvm-users] Publishing XMLVM applications

[Tor L. <tm...@ik...>]

Wasn't the problem with VLC (the withdrawal of which from the App
Store seems to have caused this discussion) that some of the copyright
holders were opposed to it being offered on the App Store?

Isn't the situation very different with XMLVM, as porting apps to iOS,
implicitly then for offering them on the App Store, is the point with
it... In XMLVM's case It can't really be any surprise to copyright
holders of XMLVM library/glue code that their code gets included in
iOS apps. The FSF's interpretation of the LGPL, for instance, is
irrelevant, if they have nothing to do with the software in question.

--tml

Re: [xmlvm-users] Publishing XMLVM applications

[Leo I. <leo...@gm...>]

How about you licence XMLVM under LGPL with all parts except the
compatibility library, which you licence under public domain? Because you
can't do anything with the library without xmlvm, it can't be stolen by
proprietary software, but it can be used under apple's licence.

On Sun, Jan 9, 2011 at 4:49 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

>
> On Jan 9, 2011, at 12:25 AM, Leo Izen wrote:
>
> > I have good news. I think that the apple app store licence doesn't have
> restrictions on where the source code comes from (but I'm not sure).
> >
> > Question: Does source code created with XMLVM have to be licensed under
> LGPL? The question becomes a fact of whether any code created with xmlvm
> counts as a derivative work. My guess would be that we could bend it and say
> no. Because the code would have been written by the developer, it was from
> scratch. XMLVM just converted it (from java to c/objective-c) so it wasn't
> derived from XMLVM, it was just a component of it. i.e. If I write a
> front-end to a library, then that's derivative. But if I just use one thing
> in an unrelated program (such as zlib in a word processor) then the
> unrelated program (the processor) would not be derived from the used code
> (zlib). This is ok because we are using LGPL, so this theory applies. As
> long as developers of xmlvm don't go ahead and sue users of xmlvm for not
> licensing xmlvm-converted code under LGPL (which they shouldn't be able to
> do anyway) then I think we should be fine.
>
> The problem is not with the code written by a developer. This issue is
> clear and closed. All code written by you has the license you decide, as
> long as it is compatible with LGPL (which practically allows even closed
> source software to do so).
>
> The problem arises with the compatibility/glue library, which is
> distributed along your binary code (and is LGPL).
>
> Right now I don't believe there is a direct problem with the AppStore and
> the LGPL license.  But I am not a lawyer and probably Apple would prefer to
> drop an application instead of sit and solve the situation. Since we have
> the core developers agreement that the compatibility library would always be
> in a license compatible with commercial distribution, this is enough for me.
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Publishing XMLVM applications

[Panayotis K. <pan...@pa...>]

On Jan 9, 2011, at 12:25 AM, Leo Izen wrote:

> I have good news. I think that the apple app store licence doesn't have restrictions on where the source code comes from (but I'm not sure).
> 
> Question: Does source code created with XMLVM have to be licensed under LGPL? The question becomes a fact of whether any code created with xmlvm counts as a derivative work. My guess would be that we could bend it and say no. Because the code would have been written by the developer, it was from scratch. XMLVM just converted it (from java to c/objective-c) so it wasn't derived from XMLVM, it was just a component of it. i.e. If I write a front-end to a library, then that's derivative. But if I just use one thing in an unrelated program (such as zlib in a word processor) then the unrelated program (the processor) would not be derived from the used code (zlib). This is ok because we are using LGPL, so this theory applies. As long as developers of xmlvm don't go ahead and sue users of xmlvm for not licensing xmlvm-converted code under LGPL (which they shouldn't be able to do anyway) then I think we should be fine.

The problem is not with the code written by a developer. This issue is clear and closed. All code written by you has the license you decide, as long as it is compatible with LGPL (which practically allows even closed source software to do so).

The problem arises with the compatibility/glue library, which is distributed along your binary code (and is LGPL). 

Right now I don't believe there is a direct problem with the AppStore and the LGPL license.  But I am not a lawyer and probably Apple would prefer to drop an application instead of sit and solve the situation. Since we have the core developers agreement that the compatibility library would always be in a license compatible with commercial distribution, this is enough for me.