Perl 6 - the future is here, just unevenly distributed

IRC log for #openframeworks, 2015-06-14

| Channels | #openframeworks index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 w4ffles joined #openframeworks
00:32 marcocanc joined #openframeworks
00:50 iShapeNoise joined #openframeworks
01:31 meandi_1 joined #openframeworks
01:49 w4ffles_ joined #openframeworks
02:24 w4ffles joined #openframeworks
04:01 jedahan joined #openframeworks
04:29 masrodjie joined #openframeworks
04:48 masrodjie joined #openframeworks
05:48 devn joined #openframeworks
05:49 * devn waves
05:51 devn I am new to oF, and am just about to step back into the world of C++ after not touching it since college (14 years ago?)
05:52 devn I notice the oF getting started guide mentions Xcode setup. I mostly roll with Emacs or Vim. Am I crazy to try and do this with oF?
06:44 masrodjie joined #openframeworks
07:40 w4ffles joined #openframeworks
07:57 notjosh joined #openframeworks
08:03 masrodjie joined #openframeworks
10:19 _mh joined #openframeworks
11:22 _mh joined #openframeworks
11:27 bilderbuchi joined #openframeworks
11:34 _mh joined #openframeworks
11:46 notjosh joined #openframeworks
12:06 _mh joined #openframeworks
12:11 bilderbuchi joined #openframeworks
12:56 masrodjie joined #openframeworks
13:11 notjosh joined #openframeworks
13:33 Shot5Dev_ left #openframeworks
13:50 notjosh joined #openframeworks
14:35 bilderbuchi joined #openframeworks
14:48 vade joined #openframeworks
14:51 iShapeNoise joined #openframeworks
15:05 meandi joined #openframeworks
15:12 bilderbuchi joined #openframeworks
15:22 bilderbuchi joined #openframeworks
15:40 jmasterj joined #openframeworks
15:42 bilderbuchi joined #openframeworks
15:45 vade joined #openframeworks
15:46 Pisuke joined #openframeworks
15:54 _mh joined #openframeworks
16:02 jmasterj joined #openframeworks
16:11 jmasterj joined #openframeworks
16:36 arturo joined #openframeworks
16:52 admsyn joined #openframeworks
16:53 _kylemcd joined #openframeworks
16:53 _kylemcd Hey! I'm running a little late, be here around 1:10 :)
16:55 admsyn1 joined #openframeworks
16:57 bilderbuchi joined #openframeworks
16:57 pizthewiz joined #openframeworks
17:00 bakercp joined #openframeworks
17:01 _mh joined #openframeworks
17:07 bilderbuchi sooo, meeting now?
17:07 lmccart joined #openframeworks
17:07 pizthewiz Looks like we lost Kyle about 10 minutes ago
17:08 vade joined #openframeworks
17:13 kylemcd joined #openframeworks
17:13 kylemcd hi :)
17:14 bakercp hi
17:14 Topic for #openframeworks is now Welcome :) Site: http://openframeworks.cc/ Logs: http://irclog.perlgeek.de/openframeworks/ Agenda: https://openframeworks.hackpad.com/IRC-Meetup-June-14-2015
17:15 kylemcd i thought theo would be joining, but it looks like no..
17:15 kylemcd arturo is here though, so let’s get started :)
17:15 arturo hey!
17:16 kylemcd hi :)
17:16 kylemcd out of curiosity, who else is here? could you just say “hi” if you’re here?
17:16 bakercp “hi"
17:16 bilderbuchi 'hi'
17:16 bilderbuchi sorry python quotation marks :P
17:17 bakercp „hi“
17:17 admsyn1 hii
17:17 kylemcd alright, if anyone else shows up / is lurking and following, say hi too when you get a chance ;)
17:18 kylemcd this week we’re jumping right into 0.9.0
17:18 pizthewiz hi
17:18 kylemcd domamato’s pulls have all been merged, which is awesome
17:18 kylemcd https://github.com/openframeworks/openFrameworks/pulls?q=is%3Apr+author%3ADomAmato+is%3Aclosed
17:19 kylemcd what is left in terms of windows for 0.9.0?
17:19 kylemcd are there still more mingw formulas / libs left to update?
17:19 arturo there's some issues yet with that merge but is a really big step
17:19 arturo we need to get 64bits working, there's some problems with poco, i think it's actually openssl that is not compiled for 64bits
17:20 arturo and a couple other libraries, also someone has reported problems with opencv
17:20 arturo 32bits is all working
17:20 arturo also we need to do mingw
17:20 arturo i can give a try this week
17:21 bakercp I’m working on mingw as well — but wanted to ask if we want to do an upgrade to a more recent version
17:21 arturo whatever latest codeblocks is using no?
17:21 bakercp Yeah, that sounds good.
17:21 arturo i usually install msys and swap it's mingw with codeblock's
17:22 arturo otherwise it won't be compatible
17:22 bakercp Currently I’ve been using ofMinGW which was constructed using the last oF supported Codeblocks + dependencies.
17:23 bakercp I can update ofMingGW to use the latest from codeblocks 13.12
17:23 bakercp I use ofMinGW because it’s the tidy little toolchain we use on windows for ofSketch.
17:24 bakercp It was constructed using codeblocks 12.11
17:24 bakercp (the mingw gcc stuff from 12.11)
17:24 bakercp (and the precompiled libs from oF)
17:26 kylemcd ???? cool
17:26 arturo cool, we should look into changing codeblocks with something else for next release. it's pretty terrible and it doesn't seem it's going to change much
17:27 bakercp I’ll do a bit of research on getting mingw 32 / 64 working on windows this week.
17:27 vade hi
17:27 vade (randomly here at the same time :)
17:27 kylemcd hey vade :)
17:27 bakercp I know constantine has done a lot of epic work getting mingw 64 support working with cmake, etc.
17:27 kylemcd i wish this was available for students / open source users for free https://www.jetbrains.com/clion/download/download_thanks.jsp?os=mac
17:28 vade arturo: I have clean opencv 64 bit compiled (on OS X), it appears to be working fine - what are the 64 bit issues in OF ?
17:28 bilderbuchi >  changing codeblocks with something else for next release.
17:28 bilderbuchi because it doesn't change much? what is the alternative? IDE/editor war incoming ^^
17:28 kylemcd bilderbuchi a lot of the issues with c::b are mostly around usability of the gui
17:29 arturo we are missing a couple of libraries, i haven't checked opencv but someone reported problems
17:29 kylemcd like not supporting drag/drop well
17:29 prisonerjohn joined #openframeworks
17:29 arturo i think some 32bit libs have ended up in the 64 bit folders or something
17:29 kylemcd oh actually, i just realized: clion *is* free for students/open source developers
17:29 bilderbuchi this makes me think of premake/cmake again - maybe we should try to use something like this in the future so that people can just generate project fiels for the IDE tehy want/like/prefer?
17:30 bilderbuchi kyle: so, what if you're working on a commercial/closed project? does it allow commercial use?
17:31 bilderbuchi (many student offers don't)
17:31 kylemcd no i think then it’s $99. i haven’t even used it extensively, just throwing it in the ring :)
17:31 kylemcd bilderbuchi i think we want to be able to provide clear instructions to new users for at least one ide
17:32 kylemcd vs seems fine, but if we only supported it, that would mean dropping ofSketch support
17:32 bilderbuchi +1. I'd prefer if that IDE would be freely available, without strings
17:32 kylemcd so it’s important to have some other non-vs ide to give us incentive to keep the mingw libs up to date :)
17:32 bakercp Keeping ofSketch running is just a matter of keeping mingw support, which is much simpler than keeping codeblocks support.
17:33 bakercp I use VS to compile ofSketch on windows … cause codeblocks always gave me trouble.
17:33 kylemcd interesting
17:33 kylemcd theo asked recently if it was an option to drop c::b, so this makes it sound more possible than i realized
17:33 bakercp ofMinGW is just a windows toolchain for our makefile system.
17:33 bilderbuchi fully working make-based system on windows - is that possible?
17:33 bakercp yeah, ofMinGW
17:33 bakercp :)
17:33 bilderbuchi cause then IDE don't matter, right?
17:34 kylemcd so we can drop c::b support? :)
17:34 bakercp that’s how ofSketch does it.  Yeah, IDE doesn’t matter for ofSketch.  The goal with ofSketch is to have a one-click package that doesn’t require VS installed or XCode, etc.
17:35 arturo yeah dropping cb is not a problem we just need to keep mingw
17:35 bakercp @arturo, exactly.
17:35 kylemcd cool
17:36 kylemcd well it seems like 0.9.0 will support c::b anyway, but for windows we’ll be focusing more on vs and ofSketch in the future
17:36 bakercp sounds good.
17:36 kylemcd moving on..
17:36 arturo anyway we are not going to decide this now, generating the cb project once we have the libraries is not much work anyway
17:36 arturo yeah
17:36 kylemcd quick status check:
17:36 kylemcd a lot of milestoned PRs were closed since last meetup (6)
17:37 kylemcd but it would be really good for people to continue milestoning PRs when they submit or review them
17:37 kylemcd to help keep track of what needs to be looked at soon
17:38 kylemcd issues are doing well too, with net total of 7 closed since last meetup :)
17:38 kylemcd the bugs are sitll primarily in windows, with smaller issues elsewhere
17:38 kylemcd but we’re entering the home stretch where it’s obvious that we wouldn’t dare consider a new feature
17:39 kylemcd :)
17:39 arturo there's a couple of relatively serious issues, like assimp loader is nor working properly
17:39 kylemcd oh right, this one is interesting:
17:39 vade oh, whats wrong with it ?
17:39 kylemcd https://github.com/openframeworks/openFrameworks/issues/3887
17:39 bilderbuchi +1 on no new features pls
17:39 vade I helped on Assimp many many moons ago
17:39 arturo not sure seems lilke textures are not working or something
17:39 arturo :)
17:39 kylemcd yeah vade it would be really cool if you took a quick look
17:40 arturo we ported it to assimp 3 but it wasn't very well tested i think
17:40 vade Oh, ha
17:40 kylemcd it’s interesting cause it looks like the colors are very slightly still there
17:40 kylemcd do you know this one?
17:40 arturo yeah might be something with lighting or the materials...
17:40 vade Yea I have my QC Assimp port to 3.0 in testing but I havent vetted it yet (im easily distracted)
17:40 vade I can compare notes
17:40 kylemcd that would be awesome
17:40 vade ok, ill tag myself on the issue
17:42 kylemcd very curious what it is.
17:42 arturo we should also update that addon at some point we are still doing the skinning in the cpu... it feels really messy now
17:42 kylemcd can you explain a little more what you mean?
17:44 vade lots of modern animations rely on using shaders to multiply the transformation matrices for the bone animations so animation happens on the GPU
17:44 vade but the issue is, if someone binds a ofShader and wants to render a model
17:44 vade and they dont implement the skinning in the shader, animation stops
17:45 kylemcd i see, so we would need to implement a shader composition tool
17:45 arturo yeah i know we should find a way of combining shader functions or something
17:45 vade CPU skinning is older, but safer IMO, for those who want to do weird shit can do
17:45 kylemcd composition in the mathematical sense, not the “composer”/gui sense
17:45 arturo we have the same problem with ofMaterial in opengl 3+
17:46 vade I frown on that idea from a complexity and a ‘jump into this and port some simple shaders’ POV for people who arent rock star devs.
17:46 vade but I have no horses in this race :)
17:46 arturo :) i know i've been thinking about it for a while
17:47 arturo for the vertex shader is ok i think though since most people will just want to get the model animated and then perhaps use fragment shaders
17:49 kylemcd added this as a 1.0 feature https://github.com/openframeworks/openFrameworks/issues/3917
17:50 kylemcd continuing with the agenda:
17:50 kylemcd Binary compatibility for existing OS X addons, libstdc++ on i386 OS X, is it worth the effort? Is the non-breaking contract extended to other platforms / architectures?
17:50 kylemcd pizthewiz added this but i don’t see him right now
17:50 arturo i think we should move to libc++ on 32bits
17:50 arturo keeping libstdc++ doesn't make sense anymore
17:51 kylemcd should we do that before or after 0.9.0
17:51 kylemcd and what work will that require?
17:51 arturo when we started porting to c++11 was about 2 years ago but now it doesn't make sense to keep the core from using c++11
17:51 arturo it's already done in the PR i sent yesterday
17:51 kylemcd great :)
17:52 bakercp +1 on just moving to libc++ for 32bit.
17:52 kylemcd so the issue was just about breaking compatibility with the (very few) addons that ship with libraries that use libstdc++, right?
17:52 arturo the only problem this might have is that it'll break addons using binary c++ libraries that use the std
17:52 arturo yeah
17:52 bakercp the multi-std lib approach for osx made sense for some reason in the past year … but we need to move on.
17:52 bakercp addon developers (like me) can recompile :)
17:53 arturo yes if we don't get full compatibility with c++11 for 0.9 it'll be a long time until we release another major version
17:53 bakercp most 3rd party libs in addons take _extra_ work to use libstdc++ at this point.
17:53 arturo yes even the apothecary scripts are too complicated because of that
17:53 bakercp @arturoc exactly.
17:55 kylemcd of wow this pr is huge https://github.com/openframeworks/openFrameworks/pull/3913
17:55 bilderbuchi yeah :-/
17:56 arturo is not really that much is just that it has the 3 libraries for all the platforms + boost needs several header files but the changes to the code are relatively simple taking into account that it almost completely removes poco
17:56 bakercp yup.  i’ve been going through it in the last day.  it’s an exciting pile of aweseome though.
17:57 pizthewiz joined #openframeworks
17:58 kylemcd speakof the devil
17:58 kylemcd pizthewiz we’re talking about https://github.com/openframeworks/openFrameworks/pull/3913 right now
17:58 arturo it mostly changes Poco file utils with boost::filesystem and std::tr2::sys in vs (which have the same api)
17:58 arturo introduces cppuri to parse uris
17:59 arturo and cpput8 which is a header only lib that makes parsing utf8 really simple in combination with c++11. with that getting full utf8 support for ofTTF should be relatively straightforward
18:00 arturo the files that have most changes are the events folder, ofUtils and ofFileUtils
18:00 bilderbuchi how much of boost are we pulling in?
18:00 pizthewiz Oh awesome - My first question was that it seems like maintaining binary compatibility for existing OS X / i386 / libstdc++ addons is a lot of work and I've lost sight if it is really required.
18:00 kylemcd just boost::filesystem and uri?
18:01 kylemcd pizthewiz the consensus seems to be that maintaining support for those addons is not worth it
18:01 arturo only boost::filesystem and boost::system ( which filesystem depends on) uri is not part of boost yet
18:01 kylemcd instead we will encourage and support the addon makers with updating their addons
18:01 arturo all of them should be part of the std at some point
18:01 kylemcd great
18:01 arturo filesystem in particular has already been aproved
18:01 pizthewiz I'm all for that - as certainly there are API changes addon developers may need for 0.9.0 anyways
18:01 kylemcd just looking through the conversation and some of the changes now, but it looks like this is definitely the right direction
18:02 arturo there's also not many addons that use c
18:02 arturo ++ binary libraries
18:02 arturo everything else should be ok even if it has a c only library or even a c++ library that won't use the std
18:02 bilderbuchi boost files are  too many to display as a list on the pr page ^^
18:03 bakercp So @arturo — perhaps this belons in the PR check, but if we’re going full on c++11, do we need utf8cpp if we have things like http://en.cppreference.com/w/cpp/locale/codecvt available now?
18:04 bakercp e.g. https://stackoverflow.com/questions/26074090/iterating-through-a-utf-8-string-in-c11
18:04 bakercp etc
18:05 arturo is there anyway to iterate over a utf8 string on an std::string (not wstring) in c++11 i haven't found any
18:05 kylemcd (looking at the addons i actually use now: bullet, fftw, oculus, pcap & libtins)
18:05 arturo and std::string is used a lot
18:05 bakercp got it.
18:05 bakercp I thought so, but I’ll look into it a little more.
18:06 arturo fftw is c only no?
18:06 kylemcd arturo: you’re right, good catch
18:06 bakercp Either way utf8cpp is clean and light and header-only.
18:06 arturo same for pcap i think
18:06 kylemcd yes
18:06 kylemcd libtins i know how to build
18:06 kylemcd oculus is probably supposed to be built for 64bit + libc++ anyway
18:06 kylemcd bullet, i can’t say
18:07 arturo @bakercp yeah is really good, i think being able to keep using std string is a really great advantage
18:07 kylemcd i’ll put an issue on ofxBullet now though, just as a warning :)
18:07 bakercp @arturo +1 for that.
18:07 arturo we can build bullet, it'll probably be broken from changes to the pi
18:07 arturo api
18:10 kylemcd ???? great
18:10 kylemcd it seems like we already covered the next question:
18:10 kylemcd Poco removal, does it leave big shoes to fill?
18:10 kylemcd any other thoughts there?
18:10 pizthewiz What is the goal of removing Poco? I do like the idea of using Boost/std things directly, but In several cases it seems as though we are trading a single Poco dependency for many smaller dependencies, no? For example, I was really hoping we'd finally fold Poco's JSON support into *core* (bakercp's ofxJSON perhaps) but now we'd need to use a third party lib like jsoncpp or json11.
18:11 prisonerjohn I'm actually using ofxbullet now in a project with OF master, and it's been compiling fine with libc++
18:11 bilderbuchi +1 on the question, eloquently put
18:11 prisonerjohn (Also, hi!)
18:11 kylemcd prisonerjohn: thanks!
18:12 kylemcd pizthewiz i think the main reason is about needing to patch poco when building for new platforms / environments
18:12 arturo there's a json header only library can't find it right now but i was thinking on bringing it as an addon or even core
18:12 arturo the main reason is that poco is too monolitic
18:12 arturo it's api is not very c++, they haven't updated to c++11 yet
18:12 arturo and their 2.0 roadmap seems even worse
18:13 arturo instead of removing the things that are already in the std like threads mutex... they are going to wrap them!
18:13 arturo everytime i port to a new platform i have to patch a lot of files in poco cause there's no way of not having a ton of stuff that we don't use at all
18:14 arturo the foundation is the minimal stuff and it's huge and includes things that are very platform specific
18:14 pizthewiz Gotcha, so it isn't simplify motivated by removing an external dependency as much as it is outgrowing its somewhat monolithic architecture and aging API
18:14 pizthewiz Er, simply
18:14 kylemcd :)
18:14 kylemcd great
18:14 bakercp Also, Poco folks are turning their attention toward IoT development with macchina.io http://macchina.io/ so I’m not sure how much effort they are going to be devoting to keeping everything running on all platforms ...
18:15 pizthewiz Good to know, I mistakenly thought it was dependency motivated
18:15 bakercp As an avid follower of their dev process, they seem a bit stretched.
18:15 pizthewiz Thanks for clarifying, that really helps
18:15 arturo the fact that the last version in the debian repos is 1.3 somehting is very telling about an open source library
18:16 bilderbuchi lol the poco lead dev is actually austrian? i had no idea 11
18:16 bilderbuchi ^^
18:16 kylemcd his github activity is interesting too
18:16 kylemcd https://github.com/obiltschnig
18:17 bilderbuchi in what way?
18:17 kylemcd looks like he has a secret side project
18:17 kylemcd jan / feb and may vs the rest of his activity :)
18:17 pizthewiz With libc++ going into the i386 OS X build, does that then mean c++11 can be used throughout oF where appropriate?
18:18 bilderbuchi well I found the GH activity chart to be pretty misleading/opinionated at times (e.g. when you do mostly issue mgmt)
18:18 kylemcd bilderbuchi — good point
18:18 kylemcd pizthewiz i think the answer is yes, and without #defines — is that right arturo?
18:18 bilderbuchi e.g. check out mine: https://github.com/bilderbuchi
18:18 arturo yes
18:18 kylemcd woooo
18:18 kylemcd yeah for you bilderbuchi it doesn’t make any sense
18:19 kylemcd so, moving on
18:19 kylemcd we already answered this:
18:19 kylemcd c & d are mostly done here: openframeworks/openFrameworks#3913 should we merge it for 0.9?
18:19 kylemcd “yes”
18:19 kylemcd :)
18:19 kylemcd next item: ofSketch Summer Development
18:19 kylemcd bakercp?
18:19 bakercp Yes, basically just looking to put the word out to help find a person or two who can help push it to the next level.
18:19 bilderbuchi c++11 everywhere: great
18:20 bakercp Not asking for volunteers here specifically, but for help getting the word out.
18:20 kylemcd bakercp do you think it’s worth asking on twitter, or would you rather have it more word of mouth?
18:22 bakercp Hmm.  I don’t know if I have the bandwidth to manage a bunch of people helping on it at the moment, so word of mouth would probably be better.  Basically I see it is a good opportunity for someone potentially new to the oF community with some web skills / processing to join and become active in the oF community.
18:23 kylemcd ok, i didn’t teach a full class this last semester, so i don’t know anyone new right now…  but i will spread the word :)
18:23 bakercp Cool.  Thanks.
18:24 bakercp Brannon is also still helping, but he’s got some other projects going on this summer.  I’d like to get it in shape for fall b/c we’re using it in classes again.
18:24 kylemcd awesome. that’s really good to hear.
18:24 bakercp Anyway, that’s all I need.  Social networking help to get some connections.
18:24 kylemcd brannon is going to be working in nyc right? someone scooped him up.
18:25 bakercp He’s still here in Chicago for a bit longer but soon enough :)
18:25 kylemcd nice
18:25 bakercp Also, Dom Amato is here too :)
18:25 bakercp Chicago
18:25 kylemcd oh wow i didn’t realize that!
18:26 bakercp Chicago is a cool place to be for oF !
18:26 kylemcd :)
18:26 kylemcd is there anything else people want to talk about? i have one more topic i wanted to brainstorm w folks a little
18:26 bakercp I probably have take off … but will check the logs!
18:27 kylemcd cool :)
18:27 kylemcd thanks for joining!
18:27 kylemcd last item then:
18:27 kylemcd Future of OF relative to other toolkits
18:27 kylemcd i’ve been trying to get a feeling for all the different tools out there recently
18:27 kylemcd more python, javascript, frontend and backend stuff
18:28 kylemcd and i’m starting to wonder about the future of C++ for people who want to make interactive art
18:29 kylemcd when i try to figure out what the advantage is for C++, it comes down to having native performance and some popularity
18:29 kylemcd i was going through a few installations the other day and imagining how they would be architect-ed with other toolkits
18:29 kylemcd and the only things i could think of that really need native code are:
18:30 kylemcd 1. peripherals 2. image processing 3. particle systems
18:30 bilderbuchi native performance can also be had in other langs, though, or langs can call into c/etc. for the performance-critical bits
18:30 vade what about deployment to devices ?
18:30 kylemcd kind of a weird list, but that’s all i got
18:30 kylemcd right, what bilderbuchi said — c++ isn’t even essential for the native thing
18:31 kylemcd some people are really psyched about swift for example, i haven’t tried so i’m going to keep my opinions to myself
18:31 kylemcd but for 1. you can always write native wrappers exposed to a scripted language (whether it’s python or node)
18:31 kylemcd for 2. you should be using a library anyway
18:31 kylemcd and 3. is the only thing i can imagine where you want flexibility to just do whatever, without worrying about whether you have to write a shader
18:32 bilderbuchi for some perspective from a scientific programming angle - I have completely switched to python (and a bit of Matlab), and found its expressiveness etc very liberating. haven't needed big performance yet, also because many libs already call into C/fortran behidn the scenes
18:32 kylemcd that’s exactly it
18:32 arturo yeah embeded devices or however you want to call them are a really good reason there's a lot of new small boards and you need native performance on those, not necesarily c++ but why not. i've been using rust a lot lately which is really great too
18:32 bilderbuchi I'm not planning on moving away from python of back to cpp anytime soon :-)
18:32 pizthewiz joined #openframeworks
18:32 kylemcd yes rust seems really good
18:33 arturo also writing wrappers is usually more painful than using a native language directly
18:33 kylemcd that’s true
18:33 bilderbuchi hehe there's an embedded gizmo running (micro)python nowadays, so there... :D
18:33 kylemcd but how much of an OF developer’s time is spent interfacing with new peripherals?
18:33 arturo i think that's the main advantage of using c or c++ not needing wrappers for lots of libraries like opencv, devices...
18:33 kylemcd it’s nice to have that freedom, but usually it’s one person who makes a wrapper + addon and everyone uses it
18:34 arturo yes but usually that takes a long time until it happens
18:34 kylemcd yes, opencv doesn’t make js bindings for example
18:34 pizthewiz Making idiomatic wrappers is pretty difficult too
18:34 bilderbuchi +1 on pizthewiz, also because idioms are so wildly different!
18:35 kylemcd arturo what is the package management situation for rust like?
18:35 arturo i think it's exactly the reason why OF has worked so well. all those reasons where true 10 years ago too and when zach talked about the project most people thought it was never going to work. c++ for artists! :)
18:35 arturo it's pretty good
18:35 bilderbuchi (btw, from the agenda bullet, I was expecting a discussion about OF compared to cinder, processing,..., not languages ^^)
18:35 pizthewiz I think some of the interest in Swift <-> oF was the Xcode Playground angle, which I suspect is much more complex than just wrapping oF, not to mention there are a few visual REPL-like envs that work with oF today
18:36 arturo kylecmd: you have a metadata file where you put your dependencies and it downloads them from their central repo or github...
18:36 arturo is really easy
18:36 kylemcd arturo that’s super nice
18:36 kylemcd i think it’s something that c++ never had because it’s older
18:36 bilderbuchi for me personally swift would be a no-go because of supporting all/multiple platforms
18:36 arturo it even makes it easier to compile c or c++ libraries since you can script in rust itself which is so much more powerful than creating bash scripts or similar
18:37 vade Also swift is so new, its not clear what will happen outside of the walled i garden.
18:37 bilderbuchi arturo: reminds me of python's pip (and/or anaconda), it's pretty awesome
18:37 vade id be wary.
18:37 kylemcd vade +1
18:37 kylemcd i think having a repl, having package management, it’s something that is really missing from c++
18:38 arturo yeah totally
18:38 bilderbuchi repl is hard to do for a compiled lang, though. right?
18:38 arturo unless you use linux :)
18:38 kylemcd and while emscripten is interesting, it still feels like OF is not meant for the web
18:39 vade https://root.cern.ch/drupal/content/cling
18:39 vade ?
18:39 * vade shrug
18:39 kylemcd and regarding embedded devices, i don’t see why v8 can’t acheive native performance for some code, and near-native for most code
18:39 * vade has no idea emotion here
18:39 vade emiticon *
18:40 vade maybe you could build a REPL with Cling ?
18:40 vade and keep it C++
18:40 kylemcd i think there’s a reason that c++ doesn’t have a repl and it’s more about the way it’s designed to be written
18:41 kylemcd even more than a repl, i want interactive compilation/injection like running js in a browser
18:41 vade true.
18:41 kylemcd it’s like livecoding, except actually useful
18:41 vade ouch
18:41 kylemcd ;)
18:42 kylemcd there’s this toolkit that’s a few years old now called plask
18:42 kylemcd http://www.plask.org/
18:43 kylemcd it hasn’t changed much, and it’s a pain in some ways, but i think it presents an interesting alternative to the usual ideas behind what you need to make interactive installations with realtime performance
18:44 kylemcd maybe the readme is most revealing: https://github.com/deanm/plask
18:44 arturo it just seems to wrap some cocoa and gl classes and calls no?
18:44 vade plask has some nice ideas
18:45 kylemcd yes, it’s “just” wrapping those things but it builds an app that has an interactive js “shell”
18:45 kylemcd there was another toolkit that followed this direction last year i think
18:45 kylemcd can’t remember the name right now
18:45 vade fuck, I cant think of another tool that did similar shit
18:45 kylemcd i think it was using node-webkit
18:45 pizthewiz It has been interesting to see Swift projects and libs adopt Playgrounds as live / editable documentation and examples.
18:47 kylemcd omg vade what was it…!
18:47 vade well, I think im thinking of something else
18:47 vade it had processing embedded in it
18:47 arturo i think there's cases for both things like js or even vvvv or any other visual language and things like c++ or rust or swift
18:47 vade and had a weird canvas + code hybrid idea
18:47 vade like Max + Processing + uh, node based too
18:48 vade super hybrid and experimental and I couldnt get into it but wanted to
18:48 bilderbuchi vade: i know I think ...let me dig
18:48 bilderbuchi Vuo: http://vuo.org/ ?
18:48 vade Feild
18:48 bilderbuchi :-/
18:49 vade no, Vuo is.. not what im thinking
18:49 vade http://openendedgroup.com/field/OverviewBanners2.html
18:49 kylemcd field is interesting too, but not what i had in mind
18:49 vade ah ok never mind then :)
18:49 vade Vuo is interesting in that it compiles native code from the nodes - but its licensing is all sorts of fucked up and its super over engineered IMO
18:49 kylemcd anyway, the big q for me is: what is it that will set OF apart, and make it relevant 5 years from now?
18:50 arturo is this guys from berlin who released something in c# recently?
18:50 kylemcd nodebox is also interesting https://www.nodebox.net/node/
18:50 kylemcd but very restricted
18:50 vade Honestly kylemcd - I think its working examples, internal consistency, high quality and craftsmanship. Clean consistent APIs that work and make complex things easier to understand
18:51 vade whether thats in C++ or not is irrelevant I think
18:51 vade “perfection is a lot of small things done well”
18:51 bilderbuchi lol so many things I had looked at briefly one time or another... there is so much stuff out there!
18:52 bilderbuchi +1 vade
18:52 vade a lot of toolkits have flashy nice examples but when you explore them you realize basically the functionality is limited to a subset of what was in that one example
18:53 vade depth + breadth
18:53 pizthewiz I'd say addons, community, support, deployment flexibility, open planning/development/governance
18:54 arturo also pedagogically OF is interesting being a relatively low level language compared to js or python... learning about the details of how the computer works is interesting in a way and that's something that is harder with a very abstract language like something running in a browser
18:54 pizthewiz Actually, that's a current snapshot, it could certainly become more
18:55 kylemcd arturo i think that’s a really good point
18:57 kylemcd vade & pizthewiz i’d like to think those things are it too
18:57 kylemcd i’m just wondering if it’s enough in the face of the fact that everyone is spending their time everywhere else
18:58 vade to be clear, you mean not C++ ?
18:58 vade or not OF ?
18:58 kylemcd yes
18:58 kylemcd more c++ and the environment around it
18:58 kylemcd talking with phoenix perry about c++ she pointed out that the main application of it besides low-level components, embedded systems, etc, is in gaming
18:59 vade well thats basically an optimization thing - custom renderers, physics, etc, most bang for your convuluted, obfuscated buck :)
18:59 kylemcd basically
18:59 vade (confession: I am not a fan of C++)
18:59 kylemcd lol
19:00 arturo @vade do you meant this: http://www.tooll.io/
19:00 kylemcd hah, not that either — but also cool
19:01 pizthewiz This was created by one of the demoscene guys right?
19:01 arturo yeah
19:02 vade Well, perhaps it makes sense to map the problem space - OF is used on {a lot of platforms} for {interactive, installation, games, shipping apps}
19:03 vade what other languages can support that with easy support for platform native UI (ofxCocoa for example)
19:05 kylemcd yeah native ui is kind of a hard requirement to fulfill any other way
19:05 kylemcd but i’d say that’s mostly in the “shipping apps” category though
19:06 vade its also one of those subtle things IMO that lend an aura of quality and trust
19:06 vade yea, thats true
19:06 kylemcd it’s true, and something we don’t do very much of with OF anyway (thanks to things like ofxUI)
19:06 vade well, some add ons provide the capability
19:07 kylemcd i think what you three have said, vade, pizthewiz, arturo — is basically the answer for OF for the next five years
19:07 bilderbuchi guys, i gotta leave. see you around!
19:07 kylemcd see ya!
19:07 arturo see you!
19:08 kylemcd it’s pedagogy, quality, consistency, ease of use, community, flexibility, openness
19:08 kylemcd but i think on top of that we should keep abstracting what we’re learning above the language level
19:08 vade I mean, dont get me wrong, id love to see C++ die in a fire.
19:08 kylemcd lol
19:08 vade but I think, at the end of the day
19:09 arturo :)
19:09 vade if it works it works and honestly the oF code is really quite nice
19:09 vade esp compared to other C++ apis
19:09 vade so its way nicer to work with
19:09 * vade shrug
19:09 kylemcd it’s true
19:09 kylemcd i think cinder has a different part of the scene covered wrt c++
19:10 vade yea how would you classify that compared to oF in terms of niche ?
19:10 kylemcd and some things, like pedagogy, flexibility, openness, are not high priorities for cinder
19:11 kylemcd i’d say those things are the main difference. maybe ease of use is not their thing either, they value correctness and consistency first
19:11 kylemcd besides languages, i’m also wondering about libraries
19:11 kylemcd the fact that apple has released metal for desktop
19:11 kylemcd which has significantly better performance compared to opengl
19:11 kylemcd and windows is really pushing dx
19:11 kylemcd makes me wonder if opengl is only for android / linux
19:12 kylemcd is = will be
19:12 arturo opengl is going to be substituted with vulkan
19:12 kylemcd hah i didn’t even know
19:12 kylemcd what is that
19:12 arturo opengl but without global state :)
19:12 vade glNext
19:12 vade its basically vulcan across vendor
19:12 arturo haven't looked into it much yet
19:13 vade similar to Metal / Vulcan
19:13 pizthewiz It doesn't exist yet so there isn't a whole lot to look at ;0)
19:13 vade I read a good writeup of metal vs vulcan the other day
19:13 kylemcd :)
19:13 vade http://hacksoflife.blogspot.com/2015/06/os-x-metal-raw-notes.html
19:13 arturo i know but there's presentations, docs...
19:13 vade oh and Mantle too
19:14 pizthewiz There are presentations and docs on the intermediate representation the shader language uses, but nothing else
19:14 arturo it also allows some pretty neat things like having some kind of bytecode for shaders which means any programming language can potentially be used to program the gpu
19:14 kylemcd it seems like if we want to keep up to date on performance, we will need to switch to another interface to opengl soon — something that handles all the abstractions from earlier opengl that we take for granted
19:14 pizthewiz (SPIR-V)
19:14 arturo yeah
19:14 pizthewiz But Khronos was given AMD's Mantle as a starting point so it will likely be deeply rooted in that
19:15 arturo we just need to move to vulkan as whenever it's a think but our current architecture with renderer, going away from global state... wil make even more sense then
19:15 kylemcd that maeks sense
19:15 pizthewiz Which itself isn't hugely different to how Metal also works - devices / command buffers feeding command queues
19:15 vade yea actually it will fix some nuances of leaky state in GL
19:15 vade in addons etc.
19:15 vade (huge for middle ware)
19:15 pizthewiz Though the current joke is that "Hello Triangle" is now ~600 lines of code
19:16 arturo it is more or less the same in dx anyway
19:16 vade oh Ben has some more thoughts on GLNext :
19:16 vade http://hacksoflife.blogspot.com/2015/03/glnext-is-neither-opengl-nor-next.html
19:18 kylemcd i’ve got to head out, but thanks for entertaining my questions :)
19:18 kylemcd lots to think about, i want OF to stay relevant and make sure we can hold onto a great community into the future :)
19:19 kylemcd meeting adjourned + talk more soon ;)
19:20 pizthewiz ANGLE is an interesting project from Google, they implemented GL ES 2/3 on top of DX for the WebGL implementation of Chrome on Windows
19:22 bilderbuchi left #openframeworks
19:24 pizthewiz joined #openframeworks
19:45 pizthewiz joined #openframeworks
20:05 marcocanc joined #openframeworks
20:30 marcocanc joined #openframeworks
20:55 jmasterj joined #openframeworks
20:57 marcocanc joined #openframeworks
21:16 pizthewiz joined #openframeworks
21:31 lmccart joined #openframeworks
22:04 Beliq joined #openframeworks
22:40 asdfasdfasd joined #openframeworks
22:46 _mh joined #openframeworks
23:09 _mh joined #openframeworks
23:35 masrodjie joined #openframeworks
23:41 marcocanc joined #openframeworks

| Channels | #openframeworks index | Today | | Search | Google Search | Plain-Text | summary