[00:01] <Quintasan> shadeslayer: http://wstaw.org/m/2012/12/22/plasma-desktoprD2665.png
[00:01] <Quintasan> sup
[00:01] <shadeslayer> :D
[00:02] <ScottK> shadeslayer: re kraft: Don't update standards version in Ubuntu relative to what Debian has.  It's pointless diff in Ubuntu and Ubuntu policy says not to.
[00:02] <Quintasan> woah
[00:02] <shadeslayer> oh
[00:02] <Quintasan> 12.10 has LVM in options?
[00:02] <shadeslayer> ScottK: we have a policy for that?
[00:02] <shadeslayer> Quintasan: heh yeah
[00:02] <shadeslayer> Riddell got it in :P
[00:02] <ScottK> Yes.
[00:03] <shadeslayer> okay, I'll keep that in mind, want me to re-upload? ( just needs fixing of control and changelog though )
[00:03]  * ScottK fixed locally already.
[00:03] <ScottK> No need
[00:03] <shadeslayer> oh thx :)
[00:04] <shadeslayer> there wasn't anything involved in updating the policy from what I could tell, so I bumped it
[00:04] <Quintasan> I'm surprised I can read this shadeslayer
[00:05] <Quintasan> but this
[00:05] <Quintasan> http://wstaw.org/m/2012/12/22/plasma-desktopMk2665.png
[00:05] <Quintasan> gotta loved mixed translations
[00:05] <ScottK> shadeslayer: Right, but there's a general policy of not updating because it just makes more diff that we don't care about.
[00:05] <shadeslayer> ScottK: Understood.
[00:05] <ScottK> shadeslayer: BTW, ask about such packages in #ubuntu-motu so we can get you more visibility there. (in the future)
[00:05] <shadeslayer> Quintasan: hehe
[00:06] <shadeslayer> ScottK: okie
[00:06]  * shadeslayer sucks at making himself visible
[00:06] <shadeslayer> even stopped blogging :P
[00:07] <Quintasan> shadeslayer: oh yea
[00:07] <Quintasan> dude
[00:07] <Quintasan> check query
[00:08] <Riddell> Quintasan: awooga
[00:08] <Riddell> shadeslayer: got what in?
[00:09] <shadeslayer> Riddell: kde-workspace 4.9.95/raring
[00:09] <Quintasan> Riddell: awooga about what?
[00:09] <ScottK> shadeslayer: Uploaded.  Thank you for your contribution to Ubuntu.
[00:11] <Riddell> Quintasan: awooga for wanting to look into input methods
[00:11] <Quintasan> mmkay
[00:12] <shadeslayer> ScottK: thx :)
[00:15] <yofel> uh...
[00:16]  * yofel wanted to check if software-properties-kde works right with py3 and got this instead:
[00:16] <yofel>   File "/usr/lib/python3/dist-packages/softwareproperties/kde/SoftwarePropertiesKDE.py", line 38, in <module>
[00:16] <yofel>     from PyKDE4.kdecore import ki18n, i18n, KUrl
[00:16] <yofel> RuntimeError: the sip module implements API v9.0 but the PyKDE4.kdecore module requires API v9.1
[00:16] <yofel> I need sip from proposed?
[00:18] <Riddell> ScottK: uploaded
[00:18] <ScottK> yofel: Probably.
[00:19] <ScottK> I'll unblock it.
[00:19] <ScottK> PyQt is taking longer than i expected.
[00:20] <yofel> yep, that worked
[00:20] <ScottK> Done.
[00:27] <ScottK> Riddell: "For details see the accompanying COPYING-CMAKE-SCRIPTS file."  cmake-modules/* in kajongg is BSD license.
[00:27] <ScottK> And said license is missing ...
[00:39] <Quintasan> apachelogger: ping
[00:40] <Quintasan> ScottK: You know C well?
[00:40] <ScottK> Quintasan: Not at all.
[00:40] <Quintasan> hmm
[00:40] <Quintasan> Riddell: You?
[00:48] <yofel> Quintasan: what's the question anyway?
[00:49] <Quintasan> yofel: http://sequoia.ict.pwr.wroc.pl/~mucha/PProg/wyklad07_prezentacja.pdf
[00:49] <Quintasan> go to page 63
[00:49] <Quintasan> what the hell
[00:49] <Quintasan> int (*piksele)[obraz->wym_x];
[00:49] <Quintasan> piksele=(int(*)[obraz->wym_x]) obraz->piksele; /*inicjujemy go jak trzeba*/
[00:49] <Quintasan> do?
[00:49] <Quintasan> ignore the comments since they are in polish
[00:50] <Quintasan> yofel: The whole thing apparently creates a dynamicall two dimensional array
[00:53] <Quintasan> it seems I killed yofel with that
[00:53] <Quintasan> :P
[00:54] <yofel> not really, I'm just getting confused by all the polish
[00:54] <Quintasan> ignore the comments
[00:54] <Quintasan> they really don't say anything
[00:54] <yofel> int (*piksele)[obraz->wym_x]; should be -> piksele defined as pointer to int array with obraz->wym_x elements
[00:55] <yofel> the next line is a "simple" type cast
[00:55] <yofel> defining the data type for the malloc a few lines above
[00:56] <Quintasan> shadeslayer: see this?
[00:56] <Quintasan> he knows his stuff
[00:56] <yofel> but I'm still wondering about the 2-dimensionality
[00:57] <shadeslayer> yofel: inorite
[00:57] <Quintasan> oh
[00:57] <Quintasan> that's the thing
[00:57] <shadeslayer> as for int (*piksele)[obraz->wym_x] I've never written such code :P
[00:57] <shadeslayer> silly C
[00:57] <Quintasan> yofel: Basically he is importing an pbm image
[00:57] <Quintasan> wymX would be resolutionX
[00:57] <Quintasan> and wymY -> resolutionY
[00:57] <Quintasan> obraz -> picture
[00:58] <shadeslayer> and what yofel said makes sense now :P
[00:58] <Quintasan> if you scroll up
[00:58] <Quintasan> you can see it done ez mode i.e static array
[00:58] <shadeslayer> ohhh
[00:58] <shadeslayer> ohhhh okay
[00:59] <Quintasan> and the next excerices ask you to rewrite the previous app you were supposed to do
[00:59] <Quintasan> using dynamical array
[00:59] <Quintasan> dynamical 2d array ofc
[00:59] <Quintasan> and I was like
[00:59] <Quintasan> how the hell does this even work
[01:00] <Quintasan> how is this stuff creating twodimensional array?
[01:00] <Quintasan> I can see one dimension there
[01:00] <yofel> nah, it's using one malloc to allocate the space for the whole 2-dim array and later defines the types to slice it into pieces
[01:01] <Quintasan> for all I see he iterates through piksele like a 2d array
[01:02] <shadeslayer> *nod*
[01:02] <yofel> well, yeah
[01:03] <shadeslayer> yofel: though isn't piksele a 1d array?
[01:03] <Quintasan> I think the array doesn't know it yet :P
[01:03] <shadeslayer> hah
[01:03] <yofel> not really, it's an array of 1d arrays
[01:04] <shadeslayer> uhhhh
[01:04] <yofel> int (*piksele)[obraz->wym_x];
[01:04] <shadeslayer> does not compute
[01:04] <Quintasan> yeah
[01:05] <yofel> hm wait, how do I explain this correct
[01:05] <Quintasan> don't ask US that :P
[01:05] <shadeslayer> afaictl that defines an array of pointers
[01:05] <shadeslayer> of length obraz->wym_x
[01:05] <Quintasan> apachelogger: halp
[01:06] <yofel> I read that as a pointer to an array of int
[01:06] <Quintasan> I read that as a mindfuck (excuse the poor wording) for new students
[01:06] <yofel> which defines that 2nd dimension
[01:06] <shadeslayer> :D
[01:07] <Quintasan> yofel: Note this is apparently from my friends "introduction to programming" course :D
[01:07] <Quintasan> 7th lecture I think
[01:07] <shadeslayer> I really do fail to see the 2nd dimension there :P
[01:07] <yofel> Quintasan: this *IS* introductory material for C
[01:07]  * yofel wished he had C at uni -.-
[01:08] <yofel> shadeslayer: the next line does that I believe - it tells it that the allocated space is of 'arrays of int with size obraz->wym_x size' type
[01:08] <Quintasan> I don't think this is something to do at 7th lecture whne you spend two lectures introducing X window system
[01:08] <yofel> that will make the for loop skip exact the amount of bytes for one int array on i++
[01:09] <yofel> Quintasan: welcome to uni ;P
[01:09] <Quintasan> I wish I had this stuff instead of JAva
[01:09] <Quintasan> People who go to IT course have Java
[01:09] <Quintasan> and people who went for automation and robotics have C
[01:09] <Quintasan> the hell
[01:10] <yofel> well, that's what I saw in the company introductions here too, the electronics folk use C, the IT companies Java
[01:11] <yofel> so that's pretty close to reality
[01:11] <shadeslayer> that's normal actually :P
[01:11] <shadeslayer> Quintasan: thank god you're not learning verilog/VHDL
[01:11] <shadeslayer> I cannot parse that stuff no matter how hard I tried
[01:11]  * yofel dropped out before he got to VHDL...
[01:12] <shadeslayer> I did basic VHDL
[01:12] <shadeslayer> designed Flip Flops and switches
[01:12] <shadeslayer> mux's
[01:12] <Quintasan> WTF
[01:12] <yofel> Quintasan: do you know how C handles looping through malloc'd arrays?
[01:12] <Quintasan> is this
[01:12] <yofel> or how that loop works?
[01:12] <yofel> because it cares about the data type there
[01:12] <Quintasan> yofel: I think this would be called pointer arithmetic?
[01:13] <yofel> yes, but the pointer arithmetic does an automatic multiplication of the index with sizeof(datatype)
[01:13] <Quintasan> i.e by +1 it jumps X bytes where X is the number of bytes that certain data type uses?
[01:13] <shadeslayer> piksele=(int(*)[obraz->wym_x]) obraz->piksele < that to me reads as : the pointer to the first element in an array of length wym_x sliced off from obraz->piksele
[01:13] <yofel> that's why the typecast is in there
[01:14] <Quintasan> oh christ
[01:14] <yofel> shadeslayer: no
[01:15] <Quintasan> what is this I don't even
[01:15] <yofel> the pointer to the first element of data that is of type "int array of size wym_x"
[01:15] <Quintasan> WHAT IS THIS VHDL
[01:15] <Quintasan> TAKE IT AWAY
[01:15] <yofel> shadeslayer: so piksele[0] would indeed be the first int array
[01:15] <yofel> piksele[1] will be the next
[01:15] <shadeslayer> I see
[01:16] <shadeslayer> but then can you resolve piksele[0][1]
[01:16] <yofel> that would be bytes 4-7
[01:16] <shadeslayer> and shouldn't it be : ( piksele[0])[1]
[01:16] <shadeslayer> oh, so that does resolve? I didn't think it could
[01:17] <Quintasan> Riddell: I'll be perfectly honest
[01:17] <Quintasan> Fresh quantal install has nothing
[01:17] <Quintasan> nothing
[01:17] <shadeslayer> which is why I was confused
[01:17] <Quintasan> that looks like japanese input
[01:17] <yofel> it knows that piksele[0] is the first element, and since it knows the data type of that element it knows that [1] is the 2nd int in there
[01:17] <shadeslayer> smart ass compiler
[01:18] <shadeslayer> the code makes sense now I think :P
[01:18] <yofel> since it knows the data type, it knows that piksele[1] is *piksele + sizeof(that data type)
[01:18] <shadeslayer> right
[01:18] <shadeslayer> and we told it that data type when we added this : piksele=(int(*)[obraz->wym_x]) obraz->piksele 
[01:19] <yofel> that code is nice, but that's really not the way I'm used to doing it
[01:19] <yofel> as usually you would replace one of that lines by simply using calloc()
[01:20] <Quintasan> how the hell does piksele[0][1] resolve then?
[01:20] <shadeslayer> Quintasan: yofel just explained that
[01:21] <Quintasan> so wait
[01:21] <yofel> hm...
[01:21] <Quintasan> If I understood it correctly
[01:22] <Quintasan> piksele[0] is not an int but an array of ints?
[01:22] <shadeslayer> yofel: C is more convoluted than I thought it was
[01:22] <shadeslayer> Quintasan: piksele is an array of pointer to arrays
[01:22] <Quintasan> array of pointers
[01:22] <Quintasan> okay
[01:22] <Quintasan> that computes
[01:22] <Quintasan> to arrays
[01:22] <Quintasan> okay
[01:22] <shadeslayer> right
[01:22] <Quintasan> that computes as well
[01:22] <yofel> not really
[01:23] <shadeslayer> whut? 0.o
[01:23] <yofel> you never allocated space for the pointers
[01:23] <Quintasan> XD
[01:23] <shadeslayer> heh
[01:23] <yofel> it's a pointer to an array of arrays
[01:23]  * Quintasan 's brain explodes
[01:23] <shadeslayer> oic
[01:23] <yofel> it can't be anything else as you only have one variable and one slice of memory
[01:23] <shadeslayer> yofel: also, that's just shitty :P
[01:23] <Quintasan> yofel: SO piksele[0] (the first element) is a array of ints?
[01:24] <Quintasan> and piksele[1] would be another array of its?
[01:24] <yofel> shadeslayer: well, that's a pretty sane way to implement a 2-dim dynamic array in C IMHO ^^
[01:24] <Quintasan> ints*
[01:24] <yofel> Quintasan: right
[01:24] <Quintasan> holy shit
[01:24] <Quintasan> is it any different from
[01:24] <Quintasan> tab[100][100]?
[01:25] <shadeslayer> yofel: what if the resolution is more? :P
[01:25] <yofel> not really, but what memory address that resolves to is a matter of types
[01:25] <shadeslayer> erm
[01:25] <shadeslayer> Quintasan: ^
[01:25] <Quintasan> shadeslayer: I don't care
[01:25] <Quintasan> I wanted to know if it's different memory wise
[01:26] <shadeslayer> Quintasan: welcome to the world where people have images of different resolutions :P
[01:26] <shadeslayer> Quintasan: sure it is
[01:26] <Quintasan> that magic with wymX and wymY = 100 vs. int tab[100][100]
[01:26] <shadeslayer> then it's not
[01:26] <shadeslayer> but what if wymX and wymY are 50
[01:26] <yofel> well, I'm not sure, but wouldn't tab[100][100] be on the stack and not on the heap?
[01:26] <shadeslayer> then you're wasting half the space with a static array
[01:26] <Quintasan> they will be different duh
[01:26] <shadeslayer> yofel: that too
[01:26] <Quintasan> because they have different dimensions?
[01:27] <shadeslayer> Quintasan: huh?
[01:27] <Quintasan> yofel: but they will take the same amount of memory, won't they?
[01:27] <Quintasan> provided the size matches of course
[01:27] <shadeslayer> Quintasan: you can't do tab[wymX][wymY] where the two vars are not known
[01:27] <Quintasan> I KNOW
[01:27] <Quintasan> derp
[01:28] <shadeslayer> okay
[01:28] <shadeslayer> in terms of mem consumption, it shouldn't be different :P
[01:28] <yofel> it won't be different in simply amount of bytes
[01:28] <Quintasan> dude, I want to know if they will occupy exactly the same amount of memory when wymX and wymY are defined during runtime and they equal 50
[01:28] <yofel> as C has no metadata in arrays
[01:28] <shadeslayer> yes
[01:29] <shadeslayer> they will be equal
[01:29] <Quintasan> in other words
[01:30] <Quintasan> SUP BRO I HEARD YOU LIKE DYNAMICAL ARRAYS SO WE PUT 1D DYNAMICAL ARRAY IN YOU 1D DYNAMICAL ARRAY SO YOU CAN INTERATE WHILE YOU MALLOC WHILE YOU ITERATE
[01:30] <shadeslayer> just to make it clear, if wymX/Y are 50, and if you allocate a array of 50x50 , it should be the same
[01:31] <Quintasan> side note
[01:31] <Quintasan> asian input is non existent with clean installs
[01:33] <Quintasan> yofel, shadeslayer: Thanks, my brain is almost no working :P
[01:33]  * Quintasan goes to bed
[01:33] <shadeslayer> heh
[01:33]  * yofel is still thinking about the type difinitions
[01:34] <shadeslayer> lol
[01:34] <shadeslayer> hah
[01:34] <shadeslayer> etc/dbus-1/system.d/org.kde.active.clockconfig.conf
[01:34] <shadeslayer> xD
[01:35] <shadeslayer> I don't think we want that
[01:35] <shadeslayer> hm
[01:35] <shadeslayer> nvm, we do what that
[01:35] <shadeslayer> I read that incorrectly
[01:41] <shadeslayer> anywho
[01:41] <shadeslayer> morning everyone
[01:41] <yofel> hm
[01:41] <yofel> just learned something about C too
[01:41] <shadeslayer> ?
[01:42] <yofel> I wasn't sure why piksele was defined as one array pointer just to have its type changed in the next line
[01:42] <yofel> but to be used as an array pointer it has to be defined like that
[01:43] <shadeslayer> heh
[01:43] <yofel> i.e. it has to be the type of the first element it's later pointing to
[01:43] <shadeslayer> I see
[01:43] <yofel> otherwise the compiler barfs
[01:46] <yofel> or actually more correct: piksele=(int(*)[obraz->wym_x]) obraz->piksele; says that obraz->piksele has elements of the type of the pointer.
[01:46] <yofel> defining the type of the memory, not the pointer
[01:47]  * yofel looks at kde again to let his brain rest
[01:47] <shadeslayer> :P
[01:47] <shadeslayer> I'm just about done with plasma-mobile
[01:47] <shadeslayer> so yay :)
[01:47] <yofel> \o/
[01:51] <shadeslayer> http://paste.kde.org/629672/
[01:51] <shadeslayer> just need to make a -dev package now :D
[01:57] <shadeslayer> yofel: does plasma-active-dev sound fine?
[01:57] <yofel> sure
[02:08] <shadeslayer> plasma-mobile uploaded to ppa:kubuntu-active/ppa
[02:08] <shadeslayer> I'll do the rest later on :)
[07:22] <ScottK> Sigh.
[07:22] <ScottK> Workspace not uploaded.
[07:29] <ScottK> Riddell: workspace is a bit confused between ninjas and bzr what's supposed to be uploaded.
[11:17] <apachelogger> oh children
[11:18]  * apachelogger needs coffee
[11:18] <apachelogger> Quintasan_, yofel_, shadeslayer: that line you pasted should be obvious :P
[11:19] <apachelogger> it's an array of size wym_x, named tablica, containing pointers to ints
[11:21] <apachelogger> also the program technically leaks
[11:22] <apachelogger> so that declaration you pasted is so weird because the code is weird... first of all int* and int[] are treated as if they are the same which of course they are not
[11:23] <apachelogger> secondly a bad compiler would allocate >=5*4bytes on that line
[11:23] <apachelogger> as the code litterally says "there now shall be an array of int pointers 5 cells long"
[11:24] <apachelogger> all nice and fancy
[11:24] <apachelogger> now in the next line however comes what makes it bad code
[11:26] <apachelogger> an allocation on the heap assuming that the two dimensional array created before will be treated linear
[11:27] <apachelogger> it's allocating a memory segment >= x*y*4bytes and telling the compiler it should use that memory segment as the actual variable tablica
[11:29] <apachelogger> this program now contains the knowledge that an array in C is linear memory
[11:31] <apachelogger> it all had of course been more obvious if the variable had been int** or int[][], but oh well
[11:31]  * apachelogger thinks we should all program arm asm anyway
[11:31] <apachelogger> now coffee
[11:40] <yofel> thanks for the enlightment
[11:44] <yofel> apachelogger: wait, on which page were you? page 63 has no variable called tablica - that's a few pages before
[11:48] <yofel> and even there I don't see an array of pointers to int.
[11:48] <yofel> int* tablica[wym_x]; is an array of pointers to int
[11:49] <yofel> int (* tablica)[wym_x] is a pointer to an array of ints
[11:49] <yofel> apachelogger: or am I reading that the other way around?
[12:27] <Tm_T> packages on ninjas are good to go for installation on 12.10 ?
[12:28] <yofel> Tm_T: kate isn't done yet, otherwise yes
[12:34] <Tm_T> ok thanks
[12:51] <Riddell> yofel: awesome job on quantal there
[12:51] <yofel> uh... except kate all packages built by themselves, so it was an easy job really
[12:52] <Riddell> ssh, just take all the credit :)
[12:52] <yofel> :D
[13:05] <Tm_T> yofel: could you prod me when kate is ready to roll too and I go and install them for testing? (:
[13:07] <yofel> Tm_T: it's done now
[13:08] <Tm_T> ooh jolly good thanks
[15:24] <vibhav> Riddell: SOrry for pinging at the wrong channel, are you available?
[15:29] <Riddell> vibhav: mm?
[15:30]  * yofel finished kubuntu-batch-backport - comments welcome
[15:30] <yofel> and I'm off for the rest of the evening 
[15:30] <Riddell> thanks yofel 
[15:31] <vibhav> Riddell: pm?
[16:48] <oy> is a kubuntu alpha LiveCD available?
[16:56] <ScottK> yofel: Everything built by itself, except for the stuff I retried ....
[16:56] <tsimpson> oy: https://wiki.kubuntu.org/RaringRingtail/Alpha1/Kubuntu
[16:56] <ScottK> yofel, Riddell, apachelogger: workspace is still missing.
[17:00] <oy> tsimpson, thanks :-)
[17:59] <apachelogger> yofel: oh, must have looked on the wrong page ^^
[18:00] <apachelogger> yofel: but yeah, while drinking my coffee I realized that I was wrong
[18:00] <apachelogger> it's a pointer to an array
[18:00] <apachelogger> so that won't cause a pointless stack allocation
[18:00] <apachelogger> it's pretty much cheating the compiler though
[18:01] <kubotu> ::workspace-bugs:: [1093149] [kubuntu] default background not showed @ https://bugs.launchpad.net/bugs/1093149 (by Fabio Marconi)
[18:02] <apachelogger> ah 63 is the same thing tho
[18:02] <apachelogger> still cheating the compiler
[18:04] <apachelogger> i.e. it's not an array it's a memory segment, so accessing it via a pointer to an array and then using the pointer as first dimension is not only not obvious it defeats the purpose of declaring it as an array to begin with
[18:07] <apachelogger> so the way to do it right is either ** (which IMHO would be best seeing as there really is no array as actual data type involved in the allocation) or (*)[][] (to have the compiler help you with not abusing the memory and making it apparent to the reader that this is in fact fixed size)
[18:29] <Riddell> vibhav: you had a question?
[18:31] <Riddell> ScottK: you rejected kdiamond?
[18:57] <Riddell> oh it's a soyuz issue
[18:57] <Riddell> ScottK: kde-workspace uploaded
[18:57] <Riddell> kajongg too
[18:57] <Riddell> I don't see anything wrong with kshisen, all copyright holders in debian/copyright and FDL