These are chat archives for ramda/ramda

28th
Mar 2015
Simon Friis Vindum
@paldepind
Mar 28 2015 07:41
@CrossEye: Your demo code certainly looks cleaner. It looks more like a specification. But what would the convert function actually do? Personally I'm afraid to create something that turns out to be too inflexible which was my initial reason for going with the composeable functions approach.
Simon Friis Vindum
@paldepind
Mar 28 2015 14:02
@CrossEye @davidchambers freshly cloned Ramda fails when I run 'grunt test' or 'mocha'. Something related to 'composeL'. Is that a known thing?
Raine Virta
@raine
Mar 28 2015 14:08
you get further with make but I still get test errors
ReferenceError: flatt is not defined
Simon Friis Vindum
@paldepind
Mar 28 2015 14:12
This is the error I'm getting:
var headLens = R.lensIndex(0);
                   ^
TypeError: undefined is not a function
at Suite.<anonymous> (/home/simon/projects/ramda/test/composeL.js:8:20)
Raine Virta
@raine
Mar 28 2015 14:12
did you try make
i got the same first, make clean && make got me further
Simon Friis Vindum
@paldepind
Mar 28 2015 14:13
Odd. Make runs with no errors here.
Scott Sauyet
@CrossEye
Mar 28 2015 14:47
I'll go try now. Slow Internet connection, so it'll take a few minutes.
Scott Sauyet
@CrossEye
Mar 28 2015 14:57

Works fine for me:

git clone https://github.com/ramda/ramda
cd ramda
npm install
make test lint
grunt test

Either of the last two lines works fine, although a plain call to mocha does not.

Have there been some commits in between? Hmm.
Latest commit more than a day ago. Odd. This is a clean copy?
Scott Sauyet
@CrossEye
Mar 28 2015 15:08
@paldepind: I guess what I thought of convert doing was to accept a source object and a number of functions, create an empty output object and then mix in to that output object the results of calling each of the functions with the source object. all, allBut, and and would take that source object as a last of their curried parameters and would return new objects mapping names to pure functions. I haven't tried to implement any of this, though, still. So maybe I'm just dreaming.
Simon Friis Vindum
@paldepind
Mar 28 2015 15:33
@CrossEye, that approach makes a lot of sense! But unless there's something I'm not seeing, there might be a problem. In my string conversion example sliceFrom and sliceTo gets created based on the previously curried slice. This is nice because the user get both a curried slice and some convenience functions. But if each function gets passed the original source object (which is how I understand you) then they can't work with other converted functions? In my current implementation it's the same object that flows through all the functions (with pipe).
Btw, I've just added a of function and a omit function that tries to mimic what tries to obtain something closer to the code you posted earlier. The documentation has been updated with a new example.
@CrossEye, just to make sure I just did git clone/npm install/grunt test. The error I posted before still appears :(
Scott Sauyet
@CrossEye
Mar 28 2015 15:37
@paldepind, I think something similar could work fairly well, with more of a reduce-like implementation. Instead of passing just the source object, how about the source object and the already-converted ones? I'm still not sure, but I think this could be close.
@paldepind: what OS are you running?
Raine Virta
@raine
Mar 28 2015 15:38
paldepind: you didn't run make test lint
which builds ramda
Scott Sauyet
@CrossEye
Mar 28 2015 15:40
which only runs in POSIX-like operating systems. That's why I asked.
There is a way to build it under Windows, and I'm trying to remember it, or to see if I can get my nearly-dead old Windows machine to run.
rm dist/ramda.js
node scripts/build --complete >dist/ramda.js
pretty sure that will do it well enough on Windows. It won't include the header comment block, but it should work.
Scott Sauyet
@CrossEye
Mar 28 2015 15:46
well on windows, I guess that should be del, not rm.
Simon Friis Vindum
@paldepind
Mar 28 2015 15:49
@raine, oh. I did not know that. It wasn't mentioned here. Now I'm getting the same error you mentioned ReferenceError: flatt is not defined
I'm using Linux.
@CrossEye, I'm thinking about a reduce-like implementation. But I'm not sure what it adds compared to the current map-like implementation.
Scott Sauyet
@CrossEye
Mar 28 2015 15:55
The advantage was simply that you could pass the list of functions created so far to subsequent steps.
That part of the README is definitely out-of-date.
We do have to figure out why this isn't running in plain mocha. And I guess why you're having trouble with flatt.
Any pointer to where it's looking for flatt?
Raine Virta
@raine
Mar 28 2015 15:58
i stopped getting flatt error now, weird
now i got it from grunt test
Simon Friis Vindum
@paldepind
Mar 28 2015 15:59
With grunt test I'm both getting errors regarding flatt and dissocPath.
Here is one:
8) flatten turns a nested list into one flat list:
     ReferenceError: flatt is not defined
      at flatt (/home/simon/projects/newramda/ramda/dist/ramda.js:4229:41)
      at Object.f1 [as flatten] (/home/simon/projects/newramda/ramda/dist/ramda.js:197:24)
      at Context.<anonymous> (/home/simon/projects/newramda/ramda/test/flatten.js:9:24)
Simon Friis Vindum
@paldepind
Mar 28 2015 16:01
That is exactly as what I'm seeing.
Simon Friis Vindum
@paldepind
Mar 28 2015 16:07
@CrossEye, but if you begin by copying with all or allBut why would you need the the original source after that?
Scott Sauyet
@CrossEye
Mar 28 2015 16:07
Could try removing dist/ramda.js and calling make test again? I'm wondering if for some reason that file is not rebuilding.
You might not, I'm not sure enough. I was thinking that you might want to make several independent .and calls without using .all.
That's why I still don't like the name .and. But I haven't found a better one yet.
Scott Sauyet
@CrossEye
Mar 28 2015 16:12
I wasn't specifically thinking an actual reduce, although that might be fine. It would add one layer of [ - ] to the source code to make the functions passed a list. That might be for the best anyway. Ramda is moving in that direction, removing all variadic functions.
Simon Friis Vindum
@paldepind
Mar 28 2015 16:15
@CrossEye, doesn't fix it for me. make test runt fine but grunt test still gives errors.
Simon Friis Vindum
@paldepind
Mar 28 2015 16:21
@CrossEye, Yes. I don't fancy variadic functions either. The current functionize implementation doesn't have them. What does your .and function do? Is it something similar to the to function here? It passes the converted object through the list of functions at each key and writes the result to name of that key.
Scott Sauyet
@CrossEye
Mar 28 2015 16:41
Yes, that was the idea. But again, please remember that I'm just imagining an API based on what I saw in your docs.
I don't have a clue about the issue with grunt test on some machines. Later in the day, I will try to see what happens on another machine.
Simon Friis Vindum
@paldepind
Mar 28 2015 16:49
@CrossEye, Imagining an API is a good way to get a great API! :) I'm happy to have your feedback. So my to is pretty much the same as your and, and my methods is similar to your all (I think your name is better), so if I make omit into allBut then I think the resulting API would be very close to what you proposed.
Scott Sauyet
@CrossEye
Mar 28 2015 16:54
Sounds good. I didn't like my names at all, just the flow. :smile:
This message was deleted
David Chambers
@davidchambers
Mar 28 2015 17:08
I've seen the errors about flatt and dissocPath as well (intermittently). I would love to get to the bottom of the issue.
Raine Virta
@raine
Mar 28 2015 17:09
intermittent makes sense because at one point i didn't see it at all, from either make test or grunt test
David Chambers
@davidchambers
Mar 28 2015 17:10
It's also never been a problem on Travis, so it doesn't seem to be an issue with a fresh clone. So we're somehow getting into a bad state, possibly by switching branches.
David Chambers
@davidchambers
Mar 28 2015 17:18

All three errors relate to recursive named function expressions. For example:

    var _assocPath = function _assocPath(path, val, obj) {
        switch (path.length) {
        case 0:
            return obj;
        case 1:
            return _assoc(path[0], val, obj);
        default:
            return _assoc(path[0], _assocPath(_slice(path, 1), val, Object(obj[path[0]])), obj);
        }
    };

_assocPath in the default branch is somehow not defined. But the body of a named function can always reference the function by its name, no?

joekillian
@joekillian
Mar 28 2015 17:23
@CrossEye my interest is learning Javascript for web programming but starting with Ramda. Ramda integrated with a good matrix library for easy mapping functions over rows, columns, pages would provide all the capability of APL/J and a whole lot more.
Simon Friis Vindum
@paldepind
Mar 28 2015 17:26
@joekillian How would that give you everything from APL/J? In APL and J functions have rank, and that rank is used to apply them to vectors, tables, etc. The concept of rank is absent in JavaScript. How would you mimic that with a library?
Scott Sauyet
@CrossEye
Mar 28 2015 17:44
@paldepind Earlier @joekillian mentioned scijs/ndarray, and asked how well Ramda would play with this library. I have never used it and don't have a good idea, unfortunately.
Simon Friis Vindum
@paldepind
Mar 28 2015 17:48
Ah. Ok. I too don't know anything about ndarray.
David Chambers
@davidchambers
Mar 28 2015 17:56

Okay, so this succeeds:

$ grunt browserify:client && grunt mochaTest:unit

but this fails:

$ grunt browserify:client mochaTest:unit

Have I mentioned that I dislike Grunt?

joekillian
@joekillian
Mar 28 2015 18:01
@paldepind Rank would be just an pptional argument to functions that work on arrays.
Scott Sauyet
@CrossEye
Mar 28 2015 18:04
@davidchambers However I run it, grunt mochaTest:unit is failing, as is mocha
I don't think it has anything to do with grunt.
Martin Algesten
@algesten
Mar 28 2015 18:06
@davidchambers totally with you on that. just say no.
Scott Sauyet
@CrossEye
Mar 28 2015 18:06
I would still like to get away from grunt, but I do want something that will run cross-platform.
Martin Algesten
@algesten
Mar 28 2015 18:08
i find that 90% of grunt can be replaced with npm scripts. things like browserify. runs fine from the command line without grunt.
David Chambers
@davidchambers
Mar 28 2015 18:10
I'm with you, @algesten.
Scott Sauyet
@CrossEye
Mar 28 2015 18:10
I've been hearing a lot of talk of people doing that. If we can do everything we need with that cross-platform, then I'm all for it.
Raine Virta
@raine
Mar 28 2015 18:10
people have a tendency to implement everything with their new and shiny build tool
Scott Sauyet
@CrossEye
Mar 28 2015 18:11
Get rid of grunt, make and don't bring in gulp or broccoli, just use NPM. That sounds ideal.
Call out to small custom node modules for anything missing...
Raine Virta
@raine
Mar 28 2015 18:12
thus the proliferation of (gulp|grunt) plugins that wrap simple command line tools
David Chambers
@davidchambers
Mar 28 2015 18:13
That's the worst. Every tool then gets wrapped once for each build tool.
Raine Virta
@raine
Mar 28 2015 18:13
or node APIs that could be used directly
David Chambers
@davidchambers
Mar 28 2015 18:14
I'm mystified by the error we're seeing, though. How can console.log((function f() { return typeof f; }())) ever log undefined?
Simon Friis Vindum
@paldepind
Mar 28 2015 18:14
Here is a splendid article about using npm as a build tool: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/
There do seem to be some problems with getting things to run on Windows though.
Scott Sauyet
@CrossEye
Mar 28 2015 18:19
That's my concern, and as I've finally moved completely off of Windows (at least at home) there might not be anyone to see that we've broken things for our Windows users. But we could probably keep that in check.
I do think this is worth doing. And yes, I saw that excellent article.
Martin Algesten
@algesten
Mar 28 2015 18:19
is it really necessary to build on windows? i mean it’s a different thing ensuring the end result works on windows.
David Chambers
@davidchambers
Mar 28 2015 18:23
Okay. I'll work on replacing as many Grunt wrappers as possible. Hopefully we'll fix this mysterious error in the process.
Scott Sauyet
@CrossEye
Mar 28 2015 18:27
@algesten: I think it is. We no longer distribute ramda.js with a git clone. I really don't think it's fair to say "Sorry, wait for the next release if you're on Windows"
I'd actually like to fix that too. But even if that weren't the case, I also don't want to say, "No you can't contribute because you can't test your code before you submit."
One issue with mocha has to do with the exampleRunner. I was in the process of tracking that down, but have to get offline for an hour or two.
Raine Virta
@raine
Mar 28 2015 18:32
doesn't windows have Powershell or something where make and things work
David Chambers
@davidchambers
Mar 28 2015 18:32

I also don't want to say, "No you can't contribute because you can't test your code before you submit."

The tests are run via Travis, but this would be a slow feedback loop. :\

Scott Sauyet
@CrossEye
Mar 28 2015 18:45
... and our Contributions guide (rightfully) asks you to run the tests before you make a PR. But it's more than just contributing back; it's simple playing around before you do. It's really useful to know whether you've broken something. Really, would you be happy if it were the other way around and our server and our tools built on Windows only, but that's ok, since it'll happen eventually. You just have a longer wait for it. I know I don't like that when I run across it.
@raine: there are POSIX emulators such as Cygwin and mingw, but that seems to be hearkening back to the bad old days of "this only works in OS-whatever" when so much of the infrastructure is designed to improve that.
Raine Virta
@raine
Mar 28 2015 18:53
I guess there's no way to know how many of the current and potential contributors use windows
Simon Friis Vindum
@paldepind
Mar 28 2015 19:05
According to the article I linked it is possible to be Windows compatible. But it obviously requires testing the build scripts on Windows.
Martin Algesten
@algesten
Mar 28 2015 19:05
@CrossEye perhaps there’s a middle ground. Effectively what you’re saying is that running tests and building ramda.js is required to not shut out the windows people. Perhaps we can identify the few core tasks that we want cross platform and let the others be platform specific if they must.
Scott Sauyet
@CrossEye
Mar 28 2015 20:25
@algesten: I'm probably all right with that. I don't want to go through heroics to make this work on Windows, but I'm guessing that we can get most tasks working, and certainly most of the highly important ones.
Sergey Lapin
@lapanoid
Mar 28 2015 21:01
Is there some function in ramda to merge two arrays equal sizes with applying some function?
Raine Virta
@raine
Mar 28 2015 21:01
zipWith?
Sergey Lapin
@lapanoid
Mar 28 2015 21:07
Thanks, I guess it is time for sleep) Now I need to transform [1, 'a'], [2, 'b'], [3, 'c'] to [1, 2, 3], ['a', 'b', 'c']
Raine Virta
@raine
Mar 28 2015 21:08
sounds like inverse of zip
Sergey Lapin
@lapanoid
Mar 28 2015 21:10
Exactly, don't know how to do it via ramda
joekillian
@joekillian
Mar 28 2015 21:11
@lapanoid Maybe the folks behind Ramda will get some time to map Ramda over arbitrary shaped arrays - not necessarily equal in size, dimension or type. That would be very cool.....
Sergey Lapin
@lapanoid
Mar 28 2015 21:12
I can't imagine how so general function should work) inverse zip is quite simple to understand.
Raine Virta
@raine
Mar 28 2015 21:22
maybe ramda needs unzip
Raine Virta
@raine
Mar 28 2015 21:32
unzip = foldr (\(a,b) ~(as,bs) -> (a:as,b:bs)) ([],[])
Michael Hurley
@buzzdecafe
Mar 28 2015 23:19
var a = [[1, 'a'], [2, 'b'], [3, 'c']];
R.reduce(function(acc, pair) { return [R.append(R.nth(0, pair), R.nth(0, acc)), R.append(R.nth(1, pair), R.nth(1, acc))]; }, [[], []], a);
Raine Virta
@raine
Mar 28 2015 23:26
nice