IRC channel logs

2015-01-21.log

back to list of logs

<slucx>morning
<paroneayea>hello
<nalaginrut>morning guilers~
<zacts>hi guilers
<zacts>is there a good ncurses interface / api for guile?
<mark_weaver>zacts: yes, there's guile-ncurses
<mark_weaver> http://gnu.org/s/guile-ncurses
<zacts>oh thanks man
<zacts>mark_weaver: I have a goal to make a simple ed-like or ex-like editor in guile-scheme
<zacts>as a learning project
<mark_weaver>cool :)
<zacts>a new personal free software project
<zacts>for fun and learning
<zacts>I don't want it to have a direct interface from hard coded ex / ed commands into the core editor
<zacts>I want it to be more linguistic and lispy
<zacts>then I can build the ed / ex commands on top of the lispy core
<zacts>I don't know what I'm trying to say, but I hope that makes sense
<zacts>I want guile + editing utilities written in guile as the core
<zacts>so I can extend it in guile, but I'll have guile with already defined editing primitives
<zacts>I see :ex / ed commands as just one user interface of this editor
<zacts>:-)
<zacts>so the bottom layer [is guile + predefined editing primitives] -> [ user interfaces on top of this, such as an ed / ex UI ]
<zacts>hum, so how are things organized into files with guile?
<zacts>I mean guile is so flexible that it looks like I could organize things in various ways
<zacts>it's not like Java, where it is one class per file
<nalaginrut>zacts: if you use GOOPS, you have to put one class per file
<zacts>oh I see interesting
<nalaginrut>but it's not forced
<nalaginrut>and it allowed you define various classes in a file
<nalaginrut>but you lose 'private' in class
<nalaginrut>anyway, flexibility means 'it allows you do anything you like', IMO ;-)
<zacts>I would like to probably start this project in more of a functional paradigm?
<zacts>I don't know really where to begin
<zacts>except to define either a buffer class, (which doesn't seem to be functional)
<zacts>huh, or I guess I could just provide accessors and selectors for the data
<zacts>I'm thinking like a racket struct, or whatever the guile equivalent of that would be, or should it be a full-blown object
<mark_weaver>we usually use SRFI-9 structs, fwiw
<mark_weaver>I consider "object oriented programming" to be a vastly overused technique, and I get the impression that's a widely held opinion in the guile community.
<mark_weaver>we generally prefer functional programming, fwiw.
<nalaginrut>well, since record-type has inherit in r6rs, I quit OOP for a long time (actually, just one year)
<zacts>mark_weaver: cool, yeah I'm hoping to learn more of a functional paradigm with this project
<zacts>I just think so much in terms of objects, I don't know where to begin
<zacts>for an editor project like this
<zacts>this is why I think it's good to learn this stuff via real hands-on projects
<zacts>I've read much of ch1 of SICP
<zacts>but, to put it into practice shows where my knowledge is deficient
<zacts>and btw may I make a new channel for this?
<zacts>I made a #zvim channel
<zacts>for those who would like to join just to help me along the way, so I don't flood this channel
<nalaginrut>I'd recommend you talk it here, and if you have a real practical code base, you may have your new channel and mailing-list
<zacts>ah ok
<zacts>coolio
<zacts>the channel is destroyed for now
<zacts>so how should I create data in a functional paradigm?
<zacts>like something that has state like a buffer
<zacts>how do I deal with this?
<nalaginrut>hmm...functional but state?
<zacts>I'm guessing I would view as much as possible as a functional paradigm, and only when I need to interact with the world would I then have side effects?
<zacts>nalaginrut: well a buffer changes over time
<zacts>I have no idea how data such as a buffer would be represented in a functional paradigm
<zacts>I guess I could create a buffer function, that takes a point / text and returns a buffer
<zacts>the buffer would be abstracted data
<zacts>and instead of changing the state of a particular buffer, I would transform it with functions?
<nalaginrut>I have to say, whether functional or not is not a religion, it's a way we build things properly. So I never write code just for functional practice. But I understand you want to try it for educational purpose
<zacts>oh I see
<zacts>well I want to do this in a functionalish way, I don't really mean to have a strict requirement if it deters from design ideals
<nalaginrut>in some scenario I prefer stateful implementation, but I have to take care of it properly
<nalaginrut>anyway, I'm trying to eliminate all the unnecessary state according to a nice paper <<out of tar pit>>, which is another story...
<zacts>heh
<zacts>nalaginrut: I did find a lambdajam talk about this issue
<zacts>I should push it to mediagoblin
<nalaginrut>zacts: I'd recommend you use record-type if you doubt
<zacts> http://www.infoq.com/presentations/data-visibility-abstraction
<zacts>you'll have to use youtube-dl to watch it
<zacts>sorry, that sucks
<zacts>and I can't post to mediagoblin, because it's copyrighted
<zacts>I !<3 infoq
<nalaginrut>I can watch it with ladder ;-P
<zacts>cool
<zacts>see the slides, to know where in the talk (near the end) he talks about dealing with state in a functional way
<zacts>but I don't fully grok it yet
<zacts>what are guile naming conventions for constructors and selectors?
<zacts>let me pastebin what I've got
<nalaginrut>zacts: for your buffer issue, you may make a bytevector
<nalaginrut>zacts: I'd recommend you use record-type in r6rs (import rnrs module), and you don
<nalaginrut>you don't need to care about them
<zacts>iah ok
<nalaginrut>it'll generate getter&setter for you
<zacts>well I'm starting with a simple implementation of a buffer, but I can change at will due to the fact that I've abstracted it
<nalaginrut>yes, bytevector is low-level in your case
<nalaginrut>you may put some meta info in your <buffer> record-type, and write an abstract level for buffer operations
<zacts> http://sprunge.us/CcJh
<zacts>here is what I have so far
<zacts>this editor will be GPLv3+
<nalaginrut>yes, you can do it with list too
*nalaginrut is watching the video in infoq
<zacts>I want to start with lists, then optimize later on
<nalaginrut>it's fine when you have abstract level
<zacts>what string libraries are there for scheme / guile?
<zacts>and which doc can I find for these kinds of things?
<nalaginrut>just find it in the manual
<nalaginrut>there're lot
<zacts>ok
<zacts>ok I'm looking thru the guile doc
<zacts>how do I split a string into a list-of-lines?
<zacts>without the "\\n" character
<nalaginrut>read-line in rdelim
<nalaginrut>or read-delimited
<zacts>hum.. well I need this at the level of guile code
<zacts>I'm doing (define (make-text full-string-of-lines) ...)
<zacts>this text data abstraction will be changing the full-string-of-lines into a list of lines
<zacts>I need some sort of split function for strings
<zacts>I found it
<zacts>using the doc as one web page helps me grep
<zacts>ok, List/String conversion
<zacts>string-split
<zacts>:b clojure
<zacts>I need help with goops
<zacts>whenever you guys are awake
<zacts>I'm going to use records
<dsmith-work>Wednesday Greetings, Guilers
<wingo>greets
<paroneayea>hi
<please_help>anyone in here with SWIG experience?
<dsmith-work>please_help: swig for guile was unmaintained for quite a while, but I've heard rumors that it's better now.
<dsmith-work>please_help: But it's really not hard at all to wrap stuff by hand. Guile was designed to make it easy to do exactly that.
<dsmith-work>please_help: But the new ffi is probably the preferred thing to do if you can.
<davexunit>+1 for the FFI
<please_help>dmith-work: I first try to go with the FFI but ran into a wall. I'm trying to use swig to see if I can get something working to begin with.
<dsmith-work>As guile get better and better at compiling, the ffi may end up being more effient than wrapping stuff from C.
<dsmith-work>Aww. I forgot seek is down.
<please_help>My problem is that if I have a struct defined in X.h and a function in Y.h accepts a pointer to that struct, if they're part of 2 different modules, I can't use an X.h-generated <swig-pointer ...> in the binding for the Y.h funciton
<please_help>e.g. (Y-do-something (make-new-X 1 2 3) 5) ;=> wrong type argument in position 1: <swig-pointer X * [address]>
<dsmith-work>please_help: I don't think anyone here uses swig.
<please_help>rip then
<dsmith-work>please_help: The guile-cairo project is often used as a simple nice example of how to wrap stuff by hand.
<please_help>I tried to wrap by hand but then I got some weird memory corruption problem
<please_help>like an object was being freed for no reason
<davexunit>please_help: you were using the C API, not the FFI.
<davexunit>iirc, of course.
<paroneayea>ArneBab: how do you feel about Dylan's syntax?
<paroneayea>being an author of another lisp-in-a-not-sexp syntax
<please_help>davexunit you're right
<please_help>but I just tried with the FFI rather than through C-side bindings and I have problems at the same point
<please_help>segfault when trying to access struct members from the pointer scheme passes from the (make-new-X)
<mark_weaver>please_help: it sounds like maybe the garbage collector is not seeing a reference to the object, and it's getting freed.
<mark_weaver>if you tell me the details about how you are creating the object in Scheme and passing it to C, maybe I can help
<please_help>Oh no, I forgot my C "internal" function didn't return the same thing as the C wrapper for scheme, I'll start by fixing that
<please_help>alright now it's really the exact same problem as before
<please_help>*** Error in `guile': free(): invalid next size (fast): 0x000000000129c560 ***
<daviid>please_help: you should paste your C code and the guile call, people here can't help you in the dark like that [as wingo already told you before...]
<please_help>ok
<please_help> http://pastebin.com/eDkvDUV7
<please_help>here's the code
<mark_weaver>please_help: alas, I can't stay long, but at a quick glance, I suspect that those bytevectors that you're converting to pointers are getting freed.
<mark_weaver>by default, the garbage collector only recognizes pointers that point to the beginning of an allocated block.
<mark_weaver>but iirc, most bytevectors (created in the usual ways) have a header.
<mark_weaver>so merely holding onto the pointer created by 'bytevector->pointer' is probably not enough to keep it from being freed.
<mark_weaver>anyway, gotta go afk for a while. good luck!
<lloda`>does (filter-map (lambda (a) a) x) have a name?
<davexunit>lloda`: in the Ruby world, I've seen it called "compact"
<davexunit>and fyi: (lambda (a) a) can be replaced by 'identity'
<please_help>I have no idea what happened but now my code works
<dsmith-work>please_help: yey
<please_help>ok, it looks like I know what the problem was
<please_help>the lack of reference to the bytevectors generated via uint-list->bytevector
<please_help>having a ref to them -> no weird memory things; removing the ref -> weird memory thing
<please_help>Now, the call doesn't give me the right data, but that's another problem entirely
<please_help>so thanks everyone!
<davexunit>woo!
<paroneayea>please_help: your username is very anxiety inducing for me ;)
<ArneBab>paroneayea: from what I see on wikipedia¹, dylan combines somewhat heavy type declaration syntax with semicolons and end ← three things I consider as unnecessary syntax overhead. Otherwise it looks pretty good. ¹: https://de.wikipedia.org/wiki/Dylan_%28Programmiersprache%29#Multiple_Dispatch
<paroneayea>ArneBab: I think dylan has optional typing, but I've never used it so I don't really know!
<paroneayea>but good to hear :)
<ArneBab>paroneayea: I didn’t use it either. There are far more interesting programming languages I don’t know than languages I know :)
<paroneayea>:)
*paroneayea knows what you mean!