**** BEGIN LOGGING AT Mon Jul 28 03:00:01 2014
Jul 28 10:19:06 <pjetr> hey dmanderson, I read in the logs that you're redoing the API. DimitriK had a suggestion that he put in a pull-request to have the possibility to add comments to classes, a bit like the php-API where other users can suggest uses, or discuss the functionality and even add some examples.
Jul 28 10:21:38 <pjetr> And I too have a suggestion, make it possible for the packages to have subpackages in the API. I come frome a AS3 background, so my project is divided as: project.something.something.something.class It'd be good to have separation in the API on all levels :)
Jul 28 10:24:10 <pjetr> this is dimitrik's repo I was talking about: https://github.com/DimitrK/api-tool-social
Jul 28 18:46:26 <SimpsonTP> hi all
Jul 28 18:51:57 <GodGinrai> hey
Jul 28 18:56:44 <SimpsonTP> dmanderson, around ?
Jul 28 19:00:54 <GodGinrai> You're the first person to speak in this channel since I joined 7 hours ago
Jul 28 19:01:04 <GodGinrai> so if he is, he's mighty quiet today
Jul 28 19:01:34 <SimpsonTP> :)
Jul 28 19:25:38 <SimpsonTP> I'm still trying to figure out in which timezone he is anyway ;)
Jul 28 19:26:21 <GodGinrai> Well, he was in either EST or CST... But I think now he's finally over on the west coast now
Jul 28 19:27:52 <SimpsonTP> ok
Jul 28 19:41:34 <dmanderson> I am CST atm
Jul 28 19:41:36 <dmanderson> :)
Jul 28 19:41:44 <dmanderson> I’ll be PST in 4 days
Jul 28 19:41:52 <dmanderson> then in a couple weeks back into CST for a conference
Jul 28 19:42:09 <dmanderson> Around now! For some reason had IRC closed
Jul 28 19:44:11 <SimpsonTP> ok
Jul 28 19:44:20 <SimpsonTP> wondered if you had a look at my stuff
Jul 28 19:44:58 <dmanderson> I started, but haven’t had a bunch of time this week
Jul 28 19:45:07 <dmanderson> finalizing leaving MN for residence
Jul 28 19:45:13 <dmanderson> Next week I’ll be on the up and up
Jul 28 19:45:40 <dmanderson> All the features look good
Jul 28 19:45:47 <dmanderson> :) I just wanted to give it a try before hitting merge
Jul 28 19:46:16 <SimpsonTP> sure, I didn't expect it to be finalized
Jul 28 19:46:37 <SimpsonTP> I've seperated a 'clone' and a 'build' phase
Jul 28 19:47:00 <SimpsonTP> this way you can have a grunt file to setup your enyo project and download all the requirements
Jul 28 19:47:07 <SimpsonTP> I've looked at bower as well
Jul 28 19:47:30 <dmanderson> yeah, we’re still undecided as a team about bower
Jul 28 19:48:00 <dmanderson> it’s unfortunate that everyone uses the web slightly different
Jul 28 19:48:01 <dmanderson> :)
Jul 28 19:49:32 <SimpsonTP> the problem with bower is that there is no way to determine a target, and then building enyo app is a nightmare
Jul 28 19:50:11 <GodGinrai> SimpsonTP: why not just use make?
Jul 28 19:51:59 <SimpsonTP> which version of make ?
Jul 28 19:52:37 <SimpsonTP> and I'm trying to create a bootplate which doesn't contain all the enyo/layout/onyx code
Jul 28 19:53:59 <SimpsonTP> which allows a simple base for a project template which downloads and installs everything you need to start with Enyo
Jul 28 19:54:15 <SimpsonTP> but also allow to have very minimal SCM repositories
Jul 28 19:54:28 <SimpsonTP> i'm fed up with putting a bootplate copy in my repos
Jul 28 19:54:41 <dmanderson> Yeah deploy.json and be done with it
Jul 28 19:54:48 <SimpsonTP> something like that
Jul 28 19:55:00 <dmanderson> I wish there was a way to get away from using boot plate
Jul 28 19:55:17 <SimpsonTP> well this grunt stuff is already helpfull
Jul 28 19:55:24 <SimpsonTP> I even managed to get it integrated into maven
Jul 28 19:56:19 <GodGinrai> SimpsonTP: GNU Make
Jul 28 19:56:22 <GodGinrai> what other make?
Jul 28 19:56:37 <GodGinrai> Also, I agree that bootplates are ridiculous
Jul 28 19:57:37 <GodGinrai> I don't use the enyo bootplate except to grab the minified enyo from the archive
Jul 28 19:58:48 <SimpsonTP> GodGinrai, I don't think that make is wise for javascript projects
Jul 28 20:00:11 <dmanderson> but it is!
Jul 28 20:00:18 <dmanderson> I use make to setup an nodevm
Jul 28 20:00:20 <dmanderson> that’s about it
Jul 28 20:00:27 <dmanderson> npm takes over from there
Jul 28 20:00:36 <GodGinrai> SimpsonTP: Why reinvent the wheel?
Jul 28 20:00:56 <dmanderson> other people reinvented the wheel already
Jul 28 20:01:06 <GodGinrai> You complain that bower doesn't have targets, but that is because it is meant to work like a repo
Jul 28 20:01:07 <dmanderson> using grunt plugins > make for javascript workflow imo
Jul 28 20:01:11 <GodGinrai> Make is what you use for targets
Jul 28 20:01:28 <dmanderson> the problem I have with bower is the flat public repository
Jul 28 20:01:53 <GodGinrai> dmanderson: Haven't used it, so I can't have any complaints about bower yet
Jul 28 20:02:13 <GodGinrai> My point is... If you are looking to have build targets, etc, that is what make is made for
Jul 28 20:02:52 <dmanderson> I think the problem is higher level than that though, because the underlying workflow for Enyo still doesn’t lend well to building for multiple targets
Jul 28 20:03:11 <GodGinrai> plus, make comes default on all linux/unix boxes.  And there are plenty of ways to do it on Windows
Jul 28 20:04:01 <dmanderson> yeah I like make :)
Jul 28 20:04:44 <GodGinrai> dmanderson: SimpsonTP seems to have ideas for targets.  If that is the case, then make is appropriate
Jul 28 20:05:09 <dmanderson> right but he still relies on deploy.js
Jul 28 20:05:13 <dmanderson> as part of the minification process
Jul 28 20:05:23 <dmanderson> that in itself relies on a work flow that is mostly about webOS
Jul 28 20:05:30 <dmanderson> and how (now LG) uses Enyo
Jul 28 20:05:42 <dmanderson> it isn’t very flexibile outside the scope of implimentation it was intended for.
Jul 28 20:05:50 <dmanderson> Which bleeds to the loader, and script walkers
Jul 28 20:06:37 <GodGinrai> dmanderson: Yea, there's no way he is going to keep the ability to minify and *not* have the excess folder structure that is the enyo bootplate unless he rewrites deploy.js
Jul 28 20:07:04 <GodGinrai> In which case, he can rewrite it using standard unix utilities
Jul 28 20:07:18 <dmanderson> heh heh, or extend grunt-enyo-builder, which he did ;-)
Jul 28 20:07:31 <dmanderson> i wrote it to solve that scenario for the media company I worked at.
Jul 28 20:07:43 <dmanderson> We needed a sane building / lock down process, that didn’t muck up our own git tree
Jul 28 20:08:07 <dmanderson> It could have been a makefile
Jul 28 20:08:12 <dmanderson> but hipsters like grunt
Jul 28 20:08:12 <dmanderson> ;-)
Jul 28 20:08:24 <GodGinrai> lol
Jul 28 20:08:38 <GodGinrai> I'll agree you with the "hipsters" thing
Jul 28 20:08:47 <GodGinrai> that seems to be all over the place in the web currently
Jul 28 20:08:59 <GodGinrai> (not grunt, but "hipsters"
Jul 28 20:11:50 <dmanderson> haha
Jul 28 20:13:20 <GodGinrai> anyways, I'm leaving work
Jul 28 20:13:22 <GodGinrai> cya later
Jul 28 20:22:49 <chall> real hipsters use Gulp
Jul 28 20:23:00 <chall> Grunt is too mainstream
Jul 28 20:45:07 <SimpsonTP> you missunderstood 'targets'
Jul 28 20:46:12 <SimpsonTP> what I meant is you can't tell bower the exact location to deploy
Jul 28 20:46:20 <SimpsonTP> as per dependency
Jul 28 20:52:13 <SimpsonTP> I'm not looking at build target, I'm looking at bootstrapping a enyo project in a way that I don't have to put the full enyo libs in my project repository.
Jul 28 20:52:32 <SimpsonTP> ( having git externals and includes is also putting enyo in my project repository )
**** ENDING LOGGING AT Tue Jul 29 03:00:00 2014