Re: [Gambas-user] Conflict discovered in file....
Hello, well, re-starting from Terminal ~ $ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk a message suggests me to run: make clean So, I run ~ $ /trunkmake clean and then I started again from ~ $ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk and so on. It worked. Thanks at all. vuott Gio 30/10/14, Benoît Minisini gam...@users.sourceforge.net ha scritto: Oggetto: Re: [Gambas-user] Conflict discovered in file A: mailing list for gambas users gambas-user@lists.sourceforge.net Data: Giovedì 30 ottobre 2014, 23:41 Le 30/10/2014 23:20, Tobias Boege a écrit : On Thu, 30 Oct 2014, Ru Vuott wrote: Hello, updating Gambas with rev. #6593, I have this message: Conflict discovered in file 'trunk/comp/src/gb.eval.highlight/.startup'. Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict, (tc) their side of conflict, (s) show all options: s What choose do you suggest ? I'm not a svn expert but if you didn't change the file, you should be fine with tc. In any case, it shouldn't matter because .startup is a generated file, created by the compiler. It carries no new information and you can just go and regenerate it. This begs the question why it is versioned in the first place... Regards, Tobi It's a bug, that file should not be in the repository. I will fix that... -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] gb.jit crash
Hi Emil, The following little project segfaults when the jit compiler is requested. If you can look at it... -- Benoît Minisini test-jit-0.0.1.tar.gz Description: application/gzip -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] gb.jit crash
Hi! Actually this will also fail: Dim a As Integer[] a = [1] The problem is with the new _convert mechanism, introduced in http://sourceforge.net/p/gambas/code/4908/. The JIT code expects the older API, which therefore crash... I haven't found out how much refactor needs to be done to support this kind of conversion yet. I'll see if I can fix this, but it might take some time cause I'm quite busy right now. /Emil 2014-10-31 17:33 GMT+01:00 Benoît Minisini gam...@users.sourceforge.net: Hi Emil, The following little project segfaults when the jit compiler is requested. If you can look at it... -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] gb.jit crash
Le 31/10/2014 21:40, Emil Lenngren a écrit : Hi! Actually this will also fail: Dim a As Integer[] a = [1] The problem is with the new _convert mechanism, introduced in http://sourceforge.net/p/gambas/code/4908/. The JIT code expects the older API, which therefore crash... I haven't found out how much refactor needs to be done to support this kind of conversion yet. I'll see if I can fix this, but it might take some time cause I'm quite busy right now. /Emil You mean that the VALUE_convert() interpreter function had been just-in-timed? -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] gb.jit crash
The problem is the signature of the _convert functions in the classes. Before they were OBJECT* _convert(CLASS* src, CLASS* class) but now they are bool _convert(CLASS* src, CLASS* class, VALUE* value). The JIT calls the function using the first one. 2014-10-31 21:49 GMT+01:00 Benoît Minisini gam...@users.sourceforge.net: Le 31/10/2014 21:40, Emil Lenngren a écrit : Hi! Actually this will also fail: Dim a As Integer[] a = [1] The problem is with the new _convert mechanism, introduced in http://sourceforge.net/p/gambas/code/4908/. The JIT code expects the older API, which therefore crash... I haven't found out how much refactor needs to be done to support this kind of conversion yet. I'll see if I can fix this, but it might take some time cause I'm quite busy right now. /Emil You mean that the VALUE_convert() interpreter function had been just-in-timed? -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] gb.jit crash
And this is done in the function JR_object_cast in gb_runtime.c, which is called from jitted code when objects are converted to other object types. 2014-10-31 21:55 GMT+01:00 Emil Lenngren emil.lenng...@gmail.com: The problem is the signature of the _convert functions in the classes. Before they were OBJECT* _convert(CLASS* src, CLASS* class) but now they are bool _convert(CLASS* src, CLASS* class, VALUE* value). The JIT calls the function using the first one. 2014-10-31 21:49 GMT+01:00 Benoît Minisini gam...@users.sourceforge.net: Le 31/10/2014 21:40, Emil Lenngren a écrit : Hi! Actually this will also fail: Dim a As Integer[] a = [1] The problem is with the new _convert mechanism, introduced in http://sourceforge.net/p/gambas/code/4908/. The JIT code expects the older API, which therefore crash... I haven't found out how much refactor needs to be done to support this kind of conversion yet. I'll see if I can fix this, but it might take some time cause I'm quite busy right now. /Emil You mean that the VALUE_convert() interpreter function had been just-in-timed? -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] gb.jit crash
Le 31/10/2014 21:56, Emil Lenngren a écrit : And this is done in the function JR_object_cast in gb_runtime.c, which is called from jitted code when objects are converted to other object types. OK, I see it... mmm... -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] JIT bug with complex string substitutions
Hi. There was a problem with the IIf function. If you had two strings as the last two arguments, but one of them was a string constant, but not the other, it failed. I fixed this in the latest revision. /Emil 2014-10-12 21:11 GMT+02:00 Emil Lenngren emil.lenng...@gmail.com: Hi. I'll check. /Emil Den 12 okt 2014 21:09 skrev Jussi Lahtinen jussi.lahti...@gmail.com: Thanks to unnecessary complexness of Finnish language and my lack of ideas, I have written some monster lines with nested Substs. JIT doesn't seem to like them. I isolated the problem to simplest possible (unusable) case. See attachment. Jussi -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Conflict discovered in file....
Uh. no, I suppose I didn't solve the problem. Well, now trying updating I obtain this message: ~ $ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: E155004: Working copy '/home/vuott/trunk' locked. svn: E155004: '/home/vuott/trunk' is already locked. What's this lock ? How do I solve the problem ? :-( Regards vuott Ven 31/10/14, Ru Vuott vu...@yahoo.it ha scritto: Oggetto: Re: [Gambas-user] Conflict discovered in file A: mailing list for gambas users gambas-user@lists.sourceforge.net Data: Venerdì 31 ottobre 2014, 16:48 Hello, well, re-starting from Terminal ~ $ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk a message suggests me to run: make clean So, I run ~ $ /trunkmake clean and then I started again from ~ $ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk and so on. It worked. Thanks at all. vuott Gio 30/10/14, Benoît Minisini gam...@users.sourceforge.net ha scritto: Oggetto: Re: [Gambas-user] Conflict discovered in file A: mailing list for gambas users gambas-user@lists.sourceforge.net Data: Giovedì 30 ottobre 2014, 23:41 Le 30/10/2014 23:20, Tobias Boege a écrit : On Thu, 30 Oct 2014, Ru Vuott wrote: Hello, updating Gambas with rev. #6593, I have this message: Conflict discovered in file 'trunk/comp/src/gb.eval.highlight/.startup'. Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, (mc) my side of conflict, (tc) their side of conflict, (s) show all options: s What choose do you suggest ? I'm not a svn expert but if you didn't change the file, you should be fine with tc. In any case, it shouldn't matter because .startup is a generated file, created by the compiler. It carries no new information and you can just go and regenerate it. This begs the question why it is versioned in the first place... Regards, Tobi It's a bug, that file should not be in the repository. I will fix that... -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Conflict discovered in file....
Le 31/10/2014 23:02, Ru Vuott a écrit : Uh. no, I suppose I didn't solve the problem. Well, now trying updating I obtain this message: ~ $ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: E155004: Working copy '/home/vuott/trunk' locked. svn: E155004: '/home/vuott/trunk' is already locked. What's this lock ? How do I solve the problem ? :-( Regards vuott A local repository is locked when a svn command has been brutally aborted, or if a svn commit is currently running (for example). If you are sure that you didn't start a svn command somewhere, do what it tells: 'svn cleanup'. It will remove the lock. -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Conflict discovered in file....
Thanks. vuott Ven 31/10/14, Benoît Minisini gam...@users.sourceforge.net ha scritto: Oggetto: Re: [Gambas-user] Conflict discovered in file A: mailing list for gambas users gambas-user@lists.sourceforge.net Data: Venerdì 31 ottobre 2014, 23:23 Le 31/10/2014 23:02, Ru Vuott a écrit : Uh. no, I suppose I didn't solve the problem. Well, now trying updating I obtain this message: ~ $ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) svn: E155004: Working copy '/home/vuott/trunk' locked. svn: E155004: '/home/vuott/trunk' is already locked. What's this lock ? How do I solve the problem ? :-( Regards vuott A local repository is locked when a svn command has been brutally aborted, or if a svn commit is currently running (for example). If you are sure that you didn't start a svn command somewhere, do what it tells: 'svn cleanup'. It will remove the lock. -- Benoît Minisini -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
