IRC channel logs


back to list of logs

***heroux_ is now known as heroux
<amz3>héllo guilers!
<fhmgufs>Question about GOOPS: How can I write a constructor that is called when I use (make <object>)?
<fhmgufs>The docs say to define (initialize (o <object>)) but how is this called?
<fhmgufs>Ok, of course it has some initargs. Now it works.
<fhmgufs>And how would I initialize the slots? With (slot-set!)?
<iyzsong>yes, or use #:init-value in the slot options. By default, variables are all 'unbound', I think it's strange and panic for some time...
<rekado>I'm supposed to write a web application wrapper around our new bioinfo pipeline, and I'd like to use Guile for that.
<rekado>problem is that I haven't done any web stuff in ages.
<rekado>do you have any recommendations for a simple web application that allows users to upload files and then processes them in the background and eventually reports back?
<rekado>maybe Artanis?
<fhmgufs>Of course a Scheme function can only evaluate to one value, right?
<ecraven>fhmgufs: (values 1 2 3)
<fhmgufs>I need to use the function gtk-tree-selection-get-selected
<fhmgufs>How can I get the mentioned 'iter'
<davexunit>fhmgufs: Scheme procedures may return zero or more values.
<fhmgufs>davexunit: Nice. And how can I get the second one?
<davexunit>call-with-values is one way
<davexunit>let-values in SRFI-11 is another
<lloda>also receive in SRFI-8
<davexunit>or (ice-9 receive)
<fhmgufs>davexunit, lloda: I'm happy with (recieve) from ice-9 now.
<fhmgufs>But I have another problem:
<fhmgufs>A function wants the type #<type>
<fhmgufs>But I only have #<<type>
<fhmgufs>What's the difference?
<davexunit>I don't understand your question
<fhmgufs>ERROR: In procedure package-name: Wrong type argument: #<<gtk-widget> 2497f10>
<fhmgufs>It should be #<gtk-widget>
<fhmgufs>What's the difference between them?
<davexunit>fhmgufs: you are confusing yourself
<davexunit>#<<gtk-widget> 2497f10> is just the printed representation of the type #<gtk-widget>
<fhmgufs>Ah, Ok.
<davexunit>more correctly, it's the printed representation of *an intance of* the type <gtk-widget>
<davexunit>#<...> is the usual style used when rendering an object as text
<fhmgufs>Ok, thanks,
<rain1>I sent a patch to guile but I think I did it wrong
<rain1>it showed up here but it didn't move the thread to 'patch available' section
<rain1>should I resend it with [PATCH] in the title?
<fhmgufs>Sorry for all my silly questions, but I've another problem:
<fhmgufs>I created a wrapper class to wrap scheme values in gobjects:
<fhmgufs>... to use them in a GtkTreeView.
<fhmgufs>The adding and so on works.
<fhmgufs>But if I want to access the data later it says that the slot is unbound.
<fhmgufs>Note that this not my real code, just the important parts.
<fhmgufs>I created a wrapper class for scheme types.
<fhmgufs>But sometimes it says the slot is unbound.
<fhmgufs>Is there a situation where this could be?
<fhmgufs>I explicitly set the data slot at construction time.
<fhmgufs>It's for a ListStore and a GtkTreeView.
<daviid>fhmgufs: without a minimal complete example I won't be able to help
<daviid>fhmgufs: but your approach seems wrong to me :) you should not [have to] wrap any type, there are wrapped already :) and you don't have a proper renderer... you should read thee example I psted yesterday, imo
<fhmgufs>I know. But is there a better way to store non GObject values in the ListStore? They shouldn't be displayed.
<daviid>fhmgufs: what is a non gobject value?
<fhmgufs>Like a Scheme structur.
<fhmgufs>daviid: The code I've written is really normal and works perfect with normal GObject derived types.
<daviid>fhmgufs: as i said, without a minimal example it's goinf difficult t help
<fhmgufs>But I need to save additional information that is not convertable to GObject and won't be accepted by the ListStore.
<fhmgufs>daviid: Are you using Guix?
<daviid>fhmgufs: you should store an acceptable value and hold a datastructure for these in scheme
<fhmgufs>Because it's difficult to make an example.
<daviid>it should be very easy to write snipset with your problem
<daviid>then I can start to look at it...
<fhmgufs>So, are you using Guix?
<daviid>but the approach sounds wrong to me, subclassing <gobject>...
<jmd>fhmgufs: A GtkListStore can store any kind of data, not just GObjects
<daviid>no not yet
<daviid>i'm on debian
<daviid>nobody's perfect :)
<fhmgufs>daviid: So I have to write an example.
<fhmgufs>Or I try it without wrapping.
<fhmgufs>... as jmd said.
<fhmgufs>jmd: How would I add these?
<jmd>fhmgufs: gtk_list_store_append
<jmd>followed by gtk_list_store_set
<fhmgufs>This adds a row.
<fhmgufs>I want to add a column.
<fhmgufs>And therefore need to specify a type.
<jmd>You cannot change the number of columns dynmically.
<jmd>However, you could write your own GtkTreeModel to do that if you need to.
<janneke>fhmgufs: does this help?
<fhmgufs>daviid: The example is ready:
<fhmgufs>I don't know whether this is good Scheme code ... but it demonstrates the thing.
<daviid>fhmgufs: will look asap, i have to finish something I'm on first
<fhmgufs>Ok, thanks.
<ozzloy>does guile 2.2 have an auto-compile banner like guile 2.0? does guile2.0 have a "shut-the-hell-up" flag (turning off auto-compile is not the same)? lastly, why isn't this off by default and turned on with something like '--auto-compile-banner=yes'?
<janneke>ozzloy: think i saw your message to -devel?
<fhmgufs>daviid: Improved example:
<janneke>i am working on two patches: skip invalid .go files and use GNU-style error messages and found that there already are too many options that i would hope nobody uses. i would like to move that auto-compile code away under some debug/verbosity flag, please no extra switches/options.
<daviid>fhmgufs: it works here
<fhmgufs>What? It works? It isn't working for me.
<daviid>what guile version are you using?
<fhmgufs>No error messages like 'unbound slot'???
<daviid>but what 2.0.x ? what's x value on your side?
<ozzloy>janneke, i have sent no message to -devel
<daviid>ozzloy: I want autocopile on and the printed messages as well, fwiw
<daviid>this, imo, should remain the defaults
<ozzloy>i am extremely surprised by this
<fhmgufs>daviid: This is the output:
<ozzloy>is there not at least a flag to turn it off? why not have it off by default and turned on by a flag?
<ozzloy>daviid, i also want autocompile on, we agree there
<ozzloy>and i see the value in the messages
<fhmgufs>daviid: If I create up to 99 items it works. 100 and more items don't work.
<fhmgufs>What's can be a reason for that?
<fhmgufs>* What
<daviid>fhmgufs: i don't know
<fhmgufs>Strange thing.
<ozzloy>janneke, oh, so you're thinking about moving this output behind a generic "--debug" flag?
<fhmgufs>ozzloy: Yes, these auto-compiling messages are annoying.
<fhmgufs>You expect to see no messages if there's no error.
<fhmgufs>Non-developers will always think sth went wrong.
<ozzloy>even when i develop a language, i expect to not get output i didn't explicitly ask for
<ozzloy>or else i miss the important message among the see of ignorable messages
<ozzloy>s/see/sea/ lol
<ozzloy>janneke, did i understand correctly that you plan on moving this output behind a generic "--debug" flag? the things i'm concerned about would definitely be addressed by that
<ozzloy>i would like that
<janneke>ozzloy: i'm not planning that but would vote for that
<janneke>i certainly do not like the idea of yet another option
<ozzloy>i'm not in favor of yet another option, per se. hiding this output behind some existing option is fine by me
<ozzloy>right now i'm installing guix. i'm installing glibc-locales. it's been going for a good 10 minutes. i'm not sure if i missed an important error message. here's what it's currently displaying. there are pages and pages above of auto-compile banner
<davexunit>sounds like you didn't compile guix
<ozzloy>totally possible. i'm following the instructions here:
<davexunit>then nvm. you installed something already compiled
<ozzloy>oh? so glibc-locales comes compiled into the binary distribution?
<ozzloy>cool cool
<ozzloy>perhaps a note should be added to the page
<ozzloy>at the bottom of binary-install steps it says to check out that page for additional tips and tricks
<davexunit>no that's not what I'm saying
<ozzloy>oh, sorry for misunderstanding
<davexunit>but Guix has already been compiled. you should run 'guix pull' to update Guix before installing anything, though
<davexunit>otherwise you'll be building everything from source
<ozzloy>oh maybe i missed a step
<ozzloy>thanks all for the help. i gtg soon
<ozzloy>davexunit, can i kill the current 'guix package -i glibc-locales' and run guix pull?
<ozzloy>or should i just let it finish now that it's going
<davexunit>package operations are atomic
<davexunit>so it's safe
<davexunit>one of the many nice features
<ozzloy>i thought that would be the case
<ozzloy>dang. failed.
<ozzloy>davexunit, fyi, moving this to #guix
<daviid>fhmgufs: i can reproduce
<fhmgufs>And how?
<fhmgufs>What's the problem?
<fhmgufs>Btw, I first wanted to iterate over all items in (get-items), sorry.
<fhmgufs>I'm still not familiar with looping in Scheme.
<rain1>you could use (for-each (lambda (item) ...) (get-items))
<daviid>I still would not subclass <gobject> but to debug, I rewrote, for scheme style programming reasons, here:
<fhmgufs>daviid: But, what would you do, instead?
<daviid>then (load "...") (add-items %store 9) (show-items %store)
<daviid>here is the output I get calling (show-items %store) a couple of times, until it fails, misteriously:
<fhmgufs>Yes, that's my problem.
<fhmgufs>Thanks for rewriting the example.
<daviid>you can see reading the exception message, that the exception is caused by the 'system' [guile, goops or guile-gnome 'side effect'] is trying to access a wrapper that does not exists: #<<wrapper> 35b93e0> this mem address, 35b93e0, is never printed before
<daviid>this is a very serious bug
<fhmgufs>So it's not my fault?
<fhmgufs>You said that you wouldn't subclass <gobject>, what would be an alternative?
<daviid>I'd store these non gobject items in vector(s)
<fhmgufs>Ok, I'll try it like that.
<fhmgufs>It had been nice to store them next to the rest for easy access. :(
<daviid>fhmgufs: let me cook something to show you
<fhmgufs>ACTION smells a great meal
<daviid>:) no big deal really, here:
<daviid>this never fails, subclassing gobject 'just like that' is really not a good idea, as I told you earlier
<rain1>was anyone able to have a look at the guile patch I sent in?
<daviid>fhmgufs: of curse you don't even need to store this integer in the store, since it is the row position itself, but for the sake of storing something ...
<rain1>I wonder if I should ping the bug author, but I don't want to be annoying
<daviid>fhmgufs: so, aside or not aside, is an 'illusion', we don't know how things are stored on the Gnome C side ... :)
<fhmgufs>Ok, thanks for the great help!
<daviid>fhmgufs: this is still not very good programming style by the way, store-item-add should receive the 'wrapper' it needs to 'store'
<daviid>fhmgufs: welcome
<fhmgufs>ACTION thanks daviid for all the help and says "Good night!"