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