Log of the #nice channel on irc.freenode.net

Using timezone: Central European Time
* CIA-4 leaves06:14
* CIA-4 joins06:15
* ChanServ leaves06:17
* ChanServ joins06:21
* ChanServ leaves06:29
* ChanServ joins06:46
* ChanServ leaves09:18
* ChanServ joins09:19
* arjanb joins10:51
* bonniot joins11:44
* HelloWorld82 joins12:08
an easy workaround for bug #921206 is to add specialized fill functions only byte and short arrays seem to be affected 12:51
<bonniot>but the pb is general, no?12:55
<arjanb>yes setting elements in a generic array doesn't work in case of bytes or shorts because they are boxed to Integer12:58
<bonniot>even if the value is in a variable of type byte?13:00
is it better to box to Integer in other cases?
<arjanb>that never happens because the problem is with Array.set and that is only used for generic arrays13:01
i think the solution is to write an generic array class and avoid java.lang.reflect.Array methods13:02
<bonniot>i meant if the value returned by the anonymous function is a byte, not an int coerced to a byte
<arjanb>i don't know13:04
<bonniot>if we box byte and short to Integer, then it must be the same13:05
i think we do that, but i don't remember why, do you?
<bonniot>ok thanks13:12
what do you mean by a generic array class?13:13
<arjanb>something like rawArray to be used for things of type T[]13:15
<bonniot>it would be a wrapper around the real array?13:18
<bonniot>with specialized versions for primitive arrays?13:22
it would give us more control, and could be faster
<bonniot>on the other hand, it would mean that calling a Nice method with a T[] parameter from Java would be akward13:23
because you could not pass a Object[], right?
<arjanb>yes but it might be possible to handle that too13:27
maybe generating 2 variants of such methods or doing conversion at the methods side13:30
<bonniot>right. the 2 variants should probably give better performance13:34
wouldn't it be better to use instanceof to discover which type of array we are dealing with?13:36
<arjanb>you mean at the start of a method that gets generic arrays?13:38
<bonniot>in ArrayGetOp13:41
<arjanb>that would mean a instanceof at each array op13:43
<bonniot>yes, but otherwise it would be a method dispatch for each op + the cost of creating wrapper objects at each call13:44
+ one more indirection (getting the value of the field of the wrapper) at each op13:45
<arjanb>not sure if follow that13:49
<bonniot>if you create the wrapper class then:13:50
when calling a generic method with an array, you need a new instance of the wrapper13:51
then inside the generic method, for each access, you need:
(dispatch of the get method, depending on the class of array)
in the implementation of get, you need to fetch the value of its field holding the real array13:52
<arjanb>i see
you only have to wrap if that hasn't happened before
a method dispatch is not slower than an instanceof13:53
but what alternative you have in mind?13:55
<bonniot>instanceof, or something similar13:56
<arjanb>instanceof what?13:57
<bonniot>like getClass + comparison with byte[].class and short[].class
of the array
* rubber joins13:59
<bonniot>hello rubber
<rubber>Hello Daniel.14:00
I've got a retyping problem...
Simple as alaways; you'll find the solution.
In java class MemoryFileBuffer I've got the follwoing:14:01
public static MemoryFileBuffer cube_buffer = new MemoryFileBuffer();
And in nice I wanted to use:
if (MemoryFileBuffer.cube_buffer....14:03
But nice only recognizes ?com.condor_edv.e3m.ncube.MemoryFileBuffer
So I tried to write a retyping like: MemoryFilerBuffer MemoryFileBuffer.cube_buffer = native MemoryFileBuffer MemoryFileBuffer.cube_buffer;
But that does not work.
<bonniot>MemoryFilerBuffer cube_buffer = native MemoryFileBuffer MemoryFileBuffer.cube_buffer;14:04
<rubber>Encountered "=".14:05
Was expecting:
"(" ...
So, the parser does not accept the retyping.14:06
MemoryFilerBuffer cube_buffer() = ...
<rubber>Hmmm, only () at the beginning delivers:
Encountered ";".14:08
Was expecting one of:
"(" ...
"." ...
With another () at the end:
Ignored retyping because no method named cube_buffer with 0 arguments was found in class com.condor_edv.e3m.ncube.MemoryFileBuffer
<bonniot>we'll get there...
<bonniot>MemoryFilerBuffer cube_buffer() = native MemoryFileBuffer.cube_buffer;14:09
(i mean that after all these trials, i will finally remember the right syntax ;-)
<rubber>:-)) Correct.
<bonniot>you also know about the 'import foo.* (!);' feature?14:11
* bonniot is away: for lunch
What is .* (!)?
All classes notnull?14:12
<arjanb>all arguments notnull14:13
* bonniot is back (gone 00:22:06)14:33
<arjanb>daniel: how would generic array code look like if not using reflect.Array anymore?14:38
<bonniot>my idea was not to stop using it completely, just to add special cases for byte and short14:39
<arjanb>reflect.Array is too slow14:42
<bonniot>but would another generic implementation be faster? that's not sure14:43
<arjanb>the problem with reflect.Array is that every operation cost a lot of instanceofs14:45
with a wrapper you have to do that only at creation14:46
<bonniot>if you have:14:47
yes, you wrap only once14:48
an indirection is also slow though14:49
especially as it can create more memory cache misses
a truly efficient optimization would be to create specialized code for the primitive types14:50
but that's a lot of work
(it's doing automatically the specialized version of fill, for instance)14:51
for now, i would think the most important is to get the code to behave correctly in all cases14:52
we could also add a specialized version of fill for performance14:53
wrappers could probably help performance, but it's more complex, and it's not the most efficient solution for the long term, so i'm not sure if it is worth it14:57
what do you think?
<arjanb>i think wrappers are a good tradeoff15:00
i don't see specialization implemented soon and they can increase the bytecode size quit a lot15:02
<bonniot>specialization only need to be done for primitive types and for the cases that are actually used, so i don't think size would be an issue (in C++ they generate all cases, not just primitive)15:04
but sure, it's probably not going to be done soon
the question is whether this is a priority, and how much work it is
<arjanb>the overhead for reflect.Array methods is > 10x compared to primitive arrays while wrapper cost about 2x15:06
<bonniot>the 2x is from the field access?15:07
<arjanb>method dispatch and field access15:08
not bad ;-)15:11
<arjanb>how much work it is depends mainly on changing the compiler to use\wrap the generic array things15:12
<bonniot>that should be doable in nice.tools.code.SpecialArray15:16
which also has the logics about converting to Lists when needed15:17
so feel free to work on this if you feel like it ;-)15:19
i can help if you have problems with the wrapping/unwrapping
<arjanb>i will take look it15:25
<CIA-4>03bonniot * 10Nice/web/index.xml: Clarification about the license of the Nice runtime.16:49
<rubber>Did already other users complain about the license?17:03
Or why did you need to clarify right now?
<bonniot>that question appeared on a blog comment17:04
i'm quite surprised how people assume things without even asking
<bonniot>especially as it would be quite silly for a language to impose the GPL on output programs
gcc is GPL, but that does not mean your C programs must be...
<rubber>Yes, that would be a really silly limitation.17:06
<CIA-4>03bonniot * 10Nice/LICENSE: Highlight the linking exception.17:39
<bonniot>that was a suggestion from Isaac17:42
<arjanb>i'm not sure about the importance of passing arrays from java code to generic nice methods17:47
<bonniot>that's not urgent i think17:51
it could be done in a later phase
* bonniot is away: ...17:57
<rubber>ok; I'm going offline for today.... cu18:39
* rubber leaves
* bonniot is back (gone 03:33:24)21:31
how is it going, arjan?
<arjanb>i started with the wrapper classes but i'm not sure whether to implement list21:33
<bonniot>yes, actually, why not share the wrappers with rawXxxArray21:34
hmm isaac is generating many bugreports
<Bluelive>bad isaac, no maar bugzilla for you ;)21:40
<bonniot>most of his former ones could be closed, no?
if they are good reports, it's useful ;-)
<arjanb>some of them are fixed but i don't know which ones21:44
<bonniot>i think all those that you commited are22:09
* HelloWorld82 leaves22:10
<bonniot>did some cleanup of the reports ;-)23:12
<arjanb>should conversions be as flexible as possible? assuming the type system catches such things23:56
<arjanb>converting one type of array to another23:59
<bonniot>arrays are non-variant, so can this ever happen?00:00
<arjanb>in java code or as side effect of autoboxing like by the array fill bug00:01
<bonniot>in java byte[] is not a subtype of int[], is it?00:02
<bonniot>why is there array conversion in the fill case?00:03
<arjanb>element conversion i mean00:04
<bonniot>byte, short and int are all boxed as Integer00:05
for long[], it might be Long or Integer
but you can simply use Number.longValue()00:06
* CIA-4 leaves00:17
* CIA-4 joins00:18

Generated by Sualtam