Hi all, I have followed the instructions from http://wiki.github.com/shoes/shoes/BuildingShoes to build shoes, I have finished installed those deps, when I tried rake, I got some error and building was stopped, after googling still no luck, I've got following error: just wondering if anyone has experienced similar issue and solved it. blah@blah:~/shoes$ rake (in /home/c2h2/shoes) rm -rf dist mkdir -p dist gcc -I. -c -oshoes/canvas.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/canvas.c shoes/canvas.c: In function ‘shoes_canvas_snapshot’: shoes/canvas.c:1422: warning: unused variable ‘waz_cr’ gcc -I. -c -oshoes/ruby.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/ruby.c shoes/ruby.c: In function ‘shoes_http_threaded’: shoes/ruby.c:4391: warning: format ‘%s’ expects type ‘char *’, but argument 3 has type ‘VALUE’ shoes/ruby.c:4391: warning: format ‘%s’ expects type ‘char *’, but argument 4 has type ‘VALUE’ shoes/ruby.c:4391: warning: format ‘%d’ expects type ‘int’, but argument 5 has type ‘VALUE’ shoes/ruby.c:4391: warning: format ‘%s’ expects type ‘char *’, but argument 7 has type ‘VALUE’ gcc -I. -c -oshoes/app.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/app.c gcc -I. -c -oshoes/internal.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/internal.c gcc -I. -c -oshoes/image.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/image.c gcc -I. -c -oshoes/world.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/world.c gcc -I. -c -oshoes/effects.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/effects.c gcc -I. -c -oshoes/native/gtk.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/native/gtk.c gcc -I. -c -oshoes/http/curl.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 shoes/http/curl.c gcc -o dist/libshoes.so shoes/canvas.o shoes/ruby.o shoes/app.o shoes/internal.o shoes/image.o shoes/world.o shoes/effects.o shoes/native/gtk.o shoes/http/curl.o -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl -fPIC -shared -lruby1.8 -lcairo -lpangocairo-1.0 -lungif -ljpeg -lrt -L/usr/lib -lcairo -pthread -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 gcc -I. -c -obin/main.o -Wall -I/usr/include -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -pthread -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/ruby/1.8/x86_64-linux -O -DSHOES_GTK -fPIC -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 bin/main.c rm -f dist/shoes rm -f dist/shoes-bin gcc -Ldist -o dist/shoes-bin bin/main.o -lruby1.8 -lcairo -lpangocairo-1.0 -lungif -ljpeg -lrt -L/usr/lib -lcairo -pthread -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lshoes -L. -Wl,-Bsymbolic-functions -rdynamic -Wl,-export-dynamic echo 'cd "$OLDPWD" LD_LIBRARY_PATH=$APPPATH $APPPATH/shoes-bin "$@"' >> dist/shoes chmod 755 dist/shoes mkdir -p dist/ruby cp -r /usr/lib/ruby/1.8 dist/ruby/lib rm -rf dist/ruby/lib/soap rm -rf dist/ruby/lib/wsdl rm -rf dist/ruby/lib/xsd cp -r req/ftsearch/lib/ftsearch dist/ruby/lib checking for main() in -lz... yes creating Makefile gcc -I. -I. -I/usr/lib/ruby/1.8/x86_64-linux -I. -fPIC -fno-strict-aliasing -g -g -O2 -fPIC -Iincludes -DRUBY_1_8 -c binject.c binject.c: In function ‘binject_exe_resources’: binject.c:116: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c:128: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c:141: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c: In function ‘binject_exe_file_copy’: binject.c:321: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c: In function ‘binject_exe_file_copy1’: binject.c:336: warning: assignment makes pointer from integer without a cast binject.c:345: error: ‘rb_io_t’ has no member named ‘fd’ binject.c: In function ‘binject_exe_load’: binject.c:576: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c:579: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c:580: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c:585: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c:591: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result binject.c: In function ‘binject_exe_save’: binject.c:659: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result make: *** [binject.o] Error 1 rake aborted! Extension build failed /home/c2h2/shoes/Rakefile:105:in `copy_ext' (See full trace by running task with --trace) thanks guys
Sadly, there are several errors on that page for Ubuntu. The current github version requires you install ruby 1.9.1 (and dev) which is not the default Ubuntu choice. (avoid the 1.9 in Synaptic - that turns out to be 1.9.0 - you want 1.9.1) Also the 'rake VIDEO=1' will not work with any modern version of VLC included by Ubuntu. A simple 'rake' should work. On Sun, 2010-08-01 at 11:08 +0800, Yiling Cao wrote: > Hi all, I have followed the instructions > from http://wiki.github.com/shoes/shoes/BuildingShoes to build shoes, > I have finished installed those deps, when I tried rake, I got some > error and building was stopped, after googling still no luck, > >
Ubuntu seems to prefer stability over current releases. :( On Sat, Jul 31, 2010 at 8:28 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > Sadly, there are several errors on that page for Ubuntu. > > The current github version requires you install ruby 1.9.1 (and dev) > which is not the default Ubuntu choice. (avoid the 1.9 in Synaptic - > that turns out to be 1.9.0 - you want 1.9.1) > > Also the 'rake VIDEO=1' will not work with any modern version of VLC > included by Ubuntu. A simple 'rake' should work. > > On Sun, 2010-08-01 at 11:08 +0800, Yiling Cao wrote: > > Hi all, I have followed the instructions > > from http://wiki.github.com/shoes/shoes/BuildingShoes to build shoes, > > I have finished installed those deps, when I tried rake, I got some > > error and building was stopped, after googling still no luck, > > > > > > > > -- ~devyn
On Sat, 2010-07-31 at 20:33 -0700, Devyn Cairns wrote: > Ubuntu seems to prefer stability over current releases. :( > Isn't that a good thing for the broad masses? That is Shoes Target, beginning programmers? Does Apple or MSFT make it easy to install all the latest programmer tools? ) If you live to compile from source and integrate a few thousand cutting edge libraries yourself into something resembling a working system, there are Linux distributions for that desire. [off soapbox] I think I'll put the 1.8.7 conditionals back in binject.c so Shoes works for everybody. I can't fix Ubuntu but I can fix Shoes.
I don't consider 1.9.1 cutting-edge :P And beginning programmers probably wouldn't be compiling it in the first place, lol. Beside that, I'm thinking Ubuntu could be a little more up-to-date than that. They don't have to be cutting-edge… just with releases that have some stability but aren't so outdated (1.9.1). I think the rolling release model really works well. On Sat, Jul 31, 2010 at 9:16 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Sat, 2010-07-31 at 20:33 -0700, Devyn Cairns wrote: > > Ubuntu seems to prefer stability over current releases. :( > > > Isn't that a good thing for the broad masses? That is Shoes Target, > beginning programmers? Does Apple or MSFT make it easy to install all > the latest programmer tools? ) If you live to compile from source and > integrate a few thousand cutting edge libraries yourself into something > resembling a working system, there are Linux distributions for that > desire. > > [off soapbox] > > I think I'll put the 1.8.7 conditionals back in binject.c so Shoes works > for everybody. I can't fix Ubuntu but I can fix Shoes. > > > > -- ~devyn
On Sat, 2010-07-31 at 21:35 -0700, Devyn Cairns wrote: > I don't consider 1.9.1 cutting-edge :P Depends on what you need for scripts and gems and the legacy depth of the scripts on your hard drive. I've got some some stuff that I will not upgrade to 1.9.x or Policeman (UTF-8 breaks it badly and it really can't be fixed until the world cleans up every last bit of their CP1252 and ISO8859 on the WWW), I use the scripts to occasionally make a few dollars (an income stream). I'll convert them to Python first or go back to the Tcl version the ruby version came from. Ruby lost it's luster with their UTF-8 choices and the threading 'issues' in 1.9.[0|1] It's what happened. Their community decision, for better or for worse. We (Shoes developers) however struggle with no English documentation of the embedding API and scant, scattered knowledge about the threading and variable aliasing of 1.9.1. Is that all fixed in 1.9.2RCx? Links, please. > > And beginning programmers probably wouldn't be compiling it in the > first place, lol. If all you have to do is type 'rake' (or the famous configure/make/install on the command line, then some beginners can compile *if* the instructions are correct. Yilings's instructions weren't correct. Our bad! We failed! We don't need to guess or impune his motives or skills. The smartest coder in the world, given the errors he saw would (correctly) ask for community wisdom. > > > Beside that, I'm thinking Ubuntu could be a little more up-to-date > than that. They don't have to be cutting-edge… just with releases that > have some stability but aren't so outdated (1.9.1). I think the > rolling release model really works well. What is this 'rolling release model' of which you speak so highly of and how does it differ from the every six months model with daily patches of Ubuntu? Which open source projects with the complexity of a *full* OS, it's apps and it's developer tools with millions of legacy users and volunteer tech support use your rolling model. We can always use a new development paradigm, if it works.
Alright, so, first off, let me say this: I know this is a rant… but could you be a *little* less negative? You're bringing me down ;-) On Sat, Jul 31, 2010 at 11:26 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Sat, 2010-07-31 at 21:35 -0700, Devyn Cairns wrote: > > I don't consider 1.9.1 cutting-edge :P > Depends on what you need for scripts and gems and the legacy depth of > the scripts on your hard drive. I've got some some stuff that I will not > upgrade to 1.9.x or Policeman (UTF-8 breaks it badly and it really can't > be fixed until the world cleans up every last bit of their CP1252 and > ISO8859 on the WWW), I use the scripts to occasionally make a few > dollars (an income stream). I'll convert them to Python first or go back > to the Tcl version the ruby version came from. Ruby lost it's luster > with their UTF-8 choices and the threading 'issues' in 1.9.[0|1] > Do 'encoding:' magic comments or force_encoding/encode methods help you at all? Just wondering. You can force the encoding to plain 8-bit ASCII if you so wish. Also, I really would like a reference / further explanation for the threading issues you speak of. I haven't personally experienced anything like that… > > It's what happened. Their community decision, for better or for worse. > We (Shoes developers) however struggle with no English documentation of > the embedding API and scant, scattered knowledge about the threading and > variable aliasing of 1.9.1. Is that all fixed in 1.9.2RCx? Links, > please. > > > > And beginning programmers probably wouldn't be compiling it in the > > first place, lol. > > If all you have to do is type 'rake' (or the famous > configure/make/install on the command line, then some beginners can > compile *if* the instructions are correct. Yilings's instructions > weren't correct. Our bad! We failed! We don't need to guess or impune > his motives or skills. The smartest coder in the world, given the errors > he saw would (correctly) ask for community wisdom. > Oh, I totally agree with that. But we really should strive to make a decent version installable without requiring the user to compile anything. The Rakefile definitely needs a lot of cleaning up, perhaps even a total rewrite (it's very messy, I've looked at it)—unless this has already been done, I haven't been following that part. > > > > > > Beside that, I'm thinking Ubuntu could be a little more up-to-date > > than that. They don't have to be cutting-edge… just with releases that > > have some stability but aren't so outdated (1.9.1). I think the > > rolling release model really works well. > > What is this 'rolling release model' of which you speak so highly of and > how does it differ from the every six months model with daily patches of > Ubuntu? Which open source projects with the complexity of a *full* OS, > it's apps and it's developer tools with millions of legacy users and > volunteer tech support use your rolling model. We can always use a new > development paradigm, if it works. > A rolling model like Arch's is nice, there's a testing phase and everything, they just get pushed out much quicker. You can also do an Agile model, where you release quite stable code every few weeks (this is done through tests that verify the stability of your application which you run consistently while working). Of course, Arch isn't the easiest to install, but there's no reason why this couldn't be done in a more beginner-friendly way. -- ~devyn
Hey Cecil- For what it's worth, I think your heart is in the right place with this rant. But... Depends on what you need for scripts and gems and the legacy depth of > the scripts on your hard drive. Any major version change breaks compatibility. That's how it works. One of the reasons that Windows sucks so hard is that they attempt an almost superhuman amount of backwards compatibility. I'd much rather just let things break. If you need to run legacy scripts, then you can install a /bin/ruby1.8 to run those scripts. > I'll convert them to Python first or go back > to the Tcl version the ruby version came from. You should always use whatever tool you feel is most appropriate for the job. > Ruby lost it's luster > with their UTF-8 choices and the threading 'issues' in 1.9.[0|1] > At least the threading issues will be fixed in 1.9.2. > It's what happened. Their community decision, for better or for worse. > We (Shoes developers) however struggle with no English documentation of > the embedding API and scant, scattered knowledge about the threading and > variable aliasing of 1.9.1. Is that all fixed in 1.9.2RCx? Links, > please. > This is something I personally need to level up on. > If all you have to do is type 'rake' (or the famous > configure/make/install on the command line, then some beginners can > compile *if* the instructions are correct. But they still shouldn't be. I'm absolutely all for making Shoes easy to compile, honestly. But, unless you're developing Shoes itself or you want to patch it somehow to build a custom Shoes, there's absolutely no reason to compile it. > Yilings's instructions > weren't correct. Our bad! We failed! We don't need to guess or impune > his motives or skills. The smartest coder in the world, given the errors > he saw would (correctly) ask for community wisdom. > You're right, we still did. These things happen. It's absolutely something that we should work to improve; I'm not sure what the best path is, though. > What is this 'rolling release model' of which you speak so highly of and > how does it differ from the every six months model with daily patches of > Ubuntu? Which open source projects with the complexity of a *full* OS, > it's apps and it's developer tools with millions of legacy users and > volunteer tech support use your rolling model. We can always use a new > development paradigm, if it works. > He's talking about Arch Linux vs. Ubuntu. http://en.wikipedia.org/wiki/Rolling_release Many distributions use a rolling release, but they're mainly the more 'hardcore' ones, like Arch and Gentoo. Sometimes, the model Ubuntu uses can be frustrating; I remember one time that Firefox 3 (I think) was released two weeks after the Ubuntu deadline, so I was stuck using Firefox 2 for six months. I absolutely do not think that Shoes should be a rolling release, though. What we _should_ do is release more often than 2 -> 3. :) Anyway, I think that a lot of these issues stem from us being a bit of a ragtag band of developers. I'm torn about the idea of adding a bit more process to Shoes development, though, because I tend to hate process. But it's possible that we have too little. If we had someone on point for documentation, on point for each OS, and on point with managing the status and progress of the project overall, I think that'd help a lot. What do you (and everyone else) think?
On Sun, 2010-08-01 at 20:31 -0400, Steve Klabnik wrote: > > > He's talking about Arch Linux vs. > Ubuntu. http://en.wikipedia.org/wiki/Rolling_release > Thanks for that link, Steve. I wonder how those distributions handled the major kernel changes 2.0 -> 2.2 -> 2.4 -> 2.6 in a rolling release manner or converting from Lilo to Grub or vice versa. Can you ever deprecate something in a rolling release like a bad file system choice? > > Many distributions use a rolling release, but they're mainly the more > 'hardcore' ones, like Arch and Gentoo. Sometimes, the model Ubuntu > uses can be frustrating; I remember one time that Firefox 3 (I think) > was released two weeks after the Ubuntu deadline, so I was stuck using > Firefox 2 for six months. Me too, on the firefox/ubuntu timing mismatch. Doesn't bother me nearly as much as the Abobe flash X64 mess because that mess continues. > > > I absolutely do not think that Shoes should be a rolling release, > though. What we _should_ do is release more often than 2 -> 3. :) I agree. > > Anyway, I think that a lot of these issues stem from us being a bit of > a ragtag band of developers. I'm torn about the idea of adding a bit > more process to Shoes development, though, because I tend to hate > process. But it's possible that we have too little. If we had someone > on point for documentation, on point for each OS, and on point with > managing the status and progress of the project overall, I think > that'd help a lot. Just imagine what _why was putting up with with Shoes, Hpricot and his other projects. Chief, cook and bottle washer takes it's toll. > > > What do you (and everyone else) think? Process is helpful until it kills progress (process death could happen at the beginning or the end). It could kill us by putting off other developers from contributing and it's kind of not Ruby like.
On Sun, 2010-08-01 at 20:31 -0400, Steve Klabnik wrote: > At least the threading issues will be fixed in 1.9.2. We hope but we don't really know. > It's what happened. Their community decision, for better or > for worse. > We (Shoes developers) however struggle with no English > documentation of > the embedding API and scant, scattered knowledge about the > threading and > variable aliasing of 1.9.1. Is that all fixed in 1.9.2RCx? > Links, > please. > > > This is something I personally need to level up on. The global scoping name space changes were mentioned a few weeks ago by ashbb if memory serves. The local variable aliasing/scoping probably doesn't effect Shoes. Both could hurt existing Shoes scripts and my whiny whiny and more whiny UTF-8 complaints can hit some scripts. But that's mostly Ruby issues and not a Shoes issue. Except they are forever intertwingdled. It's easy enough to google ruby 1.9.1 embedding documentation and discover there isn't any, in English. Might be different if you speak Japanese. It's an issue because the rules changed about how C code (like binject or http download) communicates status updates to the Ruby thread that the C was started from (think Shoes progress bar with proc that calls native code somehow). Web wisdom suggests you don't try that in 1.9.1. Practical experience says 'seg fault' if you do. Without docs you have no idea how to proceed or even know which other Shoes->C callback->Shoes interactions will fail or what to do about it. The lack of 1.9.1 English docs is a failure that says the Ruby community couldn't be bothered. I can imagine several reasons why, but each is only a speculation (projection) on my part. (1) Nobody embeds Ruby, so why bother documenting internals? (2) Rails runs (now, mostly) so what's the problem? (3) 1.9.[0|1| was really sucky and confused, so why bother with documenting internals when 1.9.2 will be available really really soon, we promise? (4) Black Helicopters funded by the Progressive Pythonista Assimilation Movement are hovering over Japan with disrupter ray guns set to "Rolling Release". :^) (5) All of the above. --Cecil
On Sun, Aug 1, 2010 at 8:55 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Sun, 2010-08-01 at 20:31 -0400, Steve Klabnik wrote: > > At least the threading issues will be fixed in 1.9.2. > We hope but we don't really know. > > > It's what happened. Their community decision, for better or > > for worse. > > We (Shoes developers) however struggle with no English > > documentation of > > the embedding API and scant, scattered knowledge about the > > threading and > > variable aliasing of 1.9.1. Is that all fixed in 1.9.2RCx? > > Links, > > please. > > > > > > This is something I personally need to level up on. > The global scoping name space changes were mentioned a few weeks ago by > ashbb if memory serves. The local variable aliasing/scoping probably > doesn't effect Shoes. Both could hurt existing Shoes scripts and my > whiny whiny and more whiny UTF-8 complaints can hit some scripts. But > that's mostly Ruby issues and not a Shoes issue. Except they are forever > intertwingdled. > I still don't see the validity of your UTF-8 complaints—I'm going to need some evidence to back that up ;] Ruby needed to switch over to Unicode eventually, although I agree that the way they did it is a little odd. > > It's easy enough to google ruby 1.9.1 embedding documentation and > discover there isn't any, in English. Might be different if you speak > Japanese. It's an issue because the rules changed about how C code (like > binject or http download) communicates status updates to the Ruby thread > that the C was started from (think Shoes progress bar with proc that > calls native code somehow). Web wisdom suggests you don't try that in > 1.9.1. Practical experience says 'seg fault' if you do. Without docs you > have no idea how to proceed or even know which other Shoes->C > callback->Shoes interactions will fail or what to do about it. > > The lack of 1.9.1 English docs is a failure that says the Ruby community > couldn't be bothered. I can imagine several reasons why, but each is > only a speculation (projection) on my part. > (1) Nobody embeds Ruby, so why bother documenting internals? > I suppose there really aren't a lot of things embedding Ruby. Oh wait! Google SketchUp! > (2) Rails runs (now, mostly) so what's the problem? > I doubt this is the reason. There are more people than you'd think who use Ruby for purposes other than web development. > (3) 1.9.[0|1| was really sucky and confused, so why bother with > documenting internals when 1.9.2 will be available really really soon, > we promise? > Possibly, we'll see. > (4) Black Helicopters funded by the Progressive Pythonista Assimilation > Movement are hovering over Japan with disrupter ray guns set to "Rolling > Release". :^) > This one made me laugh ;] > (5) All of the above. > > --Cecil > > > -- ~devyn
On Mon, 2010-08-02 at 12:48 -0700, Devyn Cairns wrote: > > > I still don't see the validity of your UTF-8 complaints—I'm going to > need some evidence to back that up ;] It's long story. I'll try to keep it short. I've got a Shoes script that reads export files from Wordpress blogs (so it's a php download of a mysql DB) dressed up to look like it's XML. It's never been valid XML so you have to parse it as lines and strings and regexps. It's also very likely to have characters that aren't US-ASCII or UTF-8. in 1.8.7 you do string ops on it through. In 1.9.1 it throws an exception since the data doesn't pass any encoding that I know of. The user could clean up the data, one error at a time, download, shoes script run (and repeat until all errors are gone). Not user friendly. As long as Raisins and 1.8.7 is available, it's not a big problem. If the user upgrades Wordpress to the latest (3.0), there are new export options which negate the need to run my Shoes script, so it's not a big problem (as a Shoes developer, the app need is now close to nil). I've got another set of ruby scripts that also have to deal with dodgey characters downloaded from from the net. Those are 100% certain to have character set issues. Yes, I could write a C program to copy the file replacing the characters with ones that are correct. I can't process the originals in Ruby 1.9.1. Catch-22's just annoys me. On the other hand, you wouldn't believe the destruction you can cause by changing MySQL's character set -- Thank you Apple MySQL team, but that was long ago and I had some blame in that mess. > > (4) Black Helicopters funded by the Progressive Pythonista > Assimilation > Movement are hovering over Japan with disrupter ray guns set > to "Rolling > Release". :^) > > > This one made me laugh ;] Good. It was supposed to. It's all good.
On Mon, Aug 2, 2010 at 7:11 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Mon, 2010-08-02 at 12:48 -0700, Devyn Cairns wrote: > > > > > > > > I still don't see the validity of your UTF-8 complaints—I'm going to > > need some evidence to back that up ;] > > It's long story. I'll try to keep it short. I've got a Shoes script > that reads export files from Wordpress blogs (so it's a php download of > a mysql DB) dressed up to look like it's XML. It's never been valid XML > so you have to parse it as lines and strings and regexps. It's also very > likely to have characters that aren't US-ASCII or UTF-8. in 1.8.7 you do > string ops on it through. In 1.9.1 it throws an exception since the data > doesn't pass any encoding that I know of. > Not even ASCII-8BIT? ;] I do believe that ASCII-8BIT is just raw octets (no enforced encoding), so give it a try. > > The user could clean up the data, one error at a time, download, shoes > script run (and repeat until all errors are gone). Not user friendly. As > long as Raisins and 1.8.7 is available, it's not a big problem. If the > user upgrades Wordpress to the latest (3.0), there are new export > options which negate the need to run my Shoes script, so it's not a big > problem (as a Shoes developer, the app need is now close to nil). > > I've got another set of ruby scripts that also have to deal with dodgey > characters downloaded from from the net. Those are 100% certain to have > character set issues. Yes, I could write a C program to copy the file > replacing the characters with ones that are correct. I can't process the > originals in Ruby 1.9.1. Catch-22's just annoys me. On the other hand, > you wouldn't believe the destruction you can cause by changing MySQL's > character set -- Thank you Apple MySQL team, but that was long ago and I > had some blame in that mess. > > > > > (4) Black Helicopters funded by the Progressive Pythonista > > Assimilation > > Movement are hovering over Japan with disrupter ray guns set > > to "Rolling > > Release". :^) > > > > > > This one made me laugh ;] > Good. It was supposed to. > > It's all good. > > > > -- ~devyn
On Tue, Aug 3, 2010 at 7:41 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > > It's long story. I'll try to keep it short. I've got a Shoes script > that reads export files from Wordpress blogs (so it's a php download of > a mysql DB) dressed up to look like it's XML. It's never been valid XML > so you have to parse it as lines and strings and regexps. It's also very > likely to have characters that aren't US-ASCII or UTF-8. in 1.8.7 you do > string ops on it through. In 1.9.1 it throws an exception since the data > doesn't pass any encoding that I know of. That's ideally what ASCII-8BIT is for. http://yehudakatz.com/2010/05/17/encodings-unabridged/ is a good read on the topic. martin
No whining in this post. You're supposed to smile at that. Que? I managed to fix that Shoes script running with Policeman and ruby 1.9.1 and I found some, how do you say, some deprecated rubyisms that don't apply in the new world of 1.9.1. It's like they took the Python way with 1.9.1 - there is only one way to do things. I'm not whining. The knowledge gained was worth the effort for me. I thank Martin for the clue and Devyn for pushing me to find a solution. I thank the rest of you for tolerance. I did confirm a Linux editbox/append refresh bug still exists in Policeman 1.9.1 (as it did in Raisins, and the thing before it). It's not a show stopper since it's an edge case that has been there forever in Linux (Windows OK) and the solution would involve some discussion about the WalkAbout release goals and we really need to push the Policeman out of the door. On Tue, 2010-08-03 at 12:49 +0530, Martin DeMello wrote: > On Tue, Aug 3, 2010 at 7:41 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > > > > It's long story. I'll try to keep it short. I've got a Shoes script > > that reads export files from Wordpress blogs (so it's a php download of > > a mysql DB) dressed up to look like it's XML. It's never been valid XML > > so you have to parse it as lines and strings and regexps. It's also very > > likely to have characters that aren't US-ASCII or UTF-8. in 1.8.7 you do > > string ops on it through. In 1.9.1 it throws an exception since the data > > doesn't pass any encoding that I know of. > > That's ideally what ASCII-8BIT is for. > http://yehudakatz.com/2010/05/17/encodings-unabridged/ is a good read > on the topic. > > martin
On Tue, Aug 3, 2010 at 9:46 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > No whining in this post. You're supposed to smile at that. Que? > > I managed to fix that Shoes script running with Policeman and ruby 1.9.1 > and I found some, how do you say, some deprecated rubyisms that don't > apply in the new world of 1.9.1. It's like they took the Python way with > 1.9.1 - there is only one way to do things. I'm not whining. The > knowledge gained was worth the effort for me. > > I thank Martin for the clue and Devyn for pushing me to find a solution. > I thank the rest of you for tolerance. I did confirm a Linux > editbox/append refresh bug still exists in Policeman 1.9.1 (as it did in > Raisins, and the thing before it). It's not a show stopper since it's an > edge case that has been there forever in Linux (Windows OK) and the > solution would involve some discussion about the WalkAbout release goals > and we really need to push the Policeman out of the door. > Yay! Although I'm not *really* sure what happened with my email… if you'll see, I replied way after you sent that messages with the same thing Martin said, basically—I'm not sure how that happened, but whatever ;] > > On Tue, 2010-08-03 at 12:49 +0530, Martin DeMello wrote: > > On Tue, Aug 3, 2010 at 7:41 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > > > > > > It's long story. I'll try to keep it short. I've got a Shoes script > > > that reads export files from Wordpress blogs (so it's a php download of > > > a mysql DB) dressed up to look like it's XML. It's never been valid XML > > > so you have to parse it as lines and strings and regexps. It's also > very > > > likely to have characters that aren't US-ASCII or UTF-8. in 1.8.7 you > do > > > string ops on it through. In 1.9.1 it throws an exception since the > data > > > doesn't pass any encoding that I know of. > > > > That's ideally what ASCII-8BIT is for. > > http://yehudakatz.com/2010/05/17/encodings-unabridged/ is a good read > > on the topic. > > > > martin > > > -- ~devyn
> > Yay! Although I'm not really sure what happened with my email… if > you'll see, I replied way after you sent that messages with the same > thing Martin said, basically—I'm not sure how that happened, but > whatever ;] There is something going on with email system. I don't get copies of my emails like I used to (some would consider that a feature)
I've heard from bluebie that she's having issues with librelist, too. Gonna have to look into it. On Aug 4, 2010 7:26 PM, "Cecil Coupe" <ccoupe@cableone.net> wrote: > >> >> Yay! Although I'm not really sure what happened with my email… if >> you'll see, I replied way after you sent that messages with the same >> thing Martin said, basically—I'm not sure how that happened, but >> whatever ;] > > There is something going on with email system. I don't get copies of my > emails like I used to (some would consider that a feature) > > > >
Hi Cecil, > I managed to fix that Shoes script running with Policeman and ruby 1.9.1 Wow, you did it! Cool! > I did confirm a Linux editbox/append refresh bug still exists in > Policeman 1.9.1 (as it did in Raisins, and the thing before it). I'd like to confirm the bug. Could you post about that into bug list: http://github.com/shoes/shoes/issues > we really need to push the Policeman out of the door. Yes, I totally agree! :) ashbb
On Wed, 2010-08-04 at 23:39 +0900, ashbb wrote: > > > I did confirm a Linux editbox/append refresh bug still exists in > > Policeman 1.9.1 (as it did in Raisins, and the thing before it). > I'd like to confirm the bug. Could you post about that into bug list: > http://github.com/shoes/shoes/issues I haven't isolated it to a simple test case that can be easily recreated. The Shoes script for Policeman, you can download from my site at www.mvmanila.com/public - pick the SplitWxr-0.3.rb. You'll also need a file of data (and you need a lot of data). From the same directory, you can download wordpress.2010-07-25.xml (10MB of my blog) Launch the shoes script and select the downloaded file and press the 'make little WXR' button (the other defaults are fine). The script is designed to suck in a huge Wordpress.wxr/xml file and spit out smaller files that don't trigger php/wordpress/ISP upload limits. Each fragment needs all the preamble and postamble xml. I set up a pseudo console using a Shoes 'para' and I define a 'puts' method that appends the string argument to the para along with a '\n' because that's how para works. The Shoes script calls the 'puts' with progress messages to display. Obviously the Shoes/GUI thread can be blocked by the long file write. It usually runs too fast to care about that. But, if the para is in a scrollable stack and the output exceeds the visible, you get the scrollbar displayed (as expected) but when when you scroll down the text that caused the scroll, nothing new is is displayed although the script is effectively finished. In Linux. Last I looked, it was OK in Windows. As I mention in the comments in the script and some old emails to _why, a 'redraw' or 'refresh' or 'flush' method is sorely missing from Shoe's core functions. Not that big a deal for my wonky script since I now hide the 'make little wxr's' button on success so the user as a better clue that it's all done. I could throw up an alert instead but this isn't about GUI design issues. In case you need a Raisins example, SplitWXR-0.2.rb. This is **not** a bug that should delay Policeman. One could easily say I've tortured para past limits and the lack of redraw/flush/redraw is for some future release. I agree.
'clear' doesn't do it for you? I haven't seen your script yet, so I'm really not sure… and I'm probably completely wrong ;] On Wed, Aug 4, 2010 at 10:10 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Wed, 2010-08-04 at 23:39 +0900, ashbb wrote: > > > > > I did confirm a Linux editbox/append refresh bug still exists in > > > Policeman 1.9.1 (as it did in Raisins, and the thing before it). > > I'd like to confirm the bug. Could you post about that into bug list: > > http://github.com/shoes/shoes/issues > > I haven't isolated it to a simple test case that can be easily > recreated. > > The Shoes script for Policeman, you can download from my site at > www.mvmanila.com/public - pick the SplitWxr-0.3.rb. You'll also need a > file of data (and you need a lot of data). From the same directory, you > can download wordpress.2010-07-25.xml (10MB of my blog) Launch the shoes > script and select the downloaded file and press the 'make little WXR' > button (the other defaults are fine). > > The script is designed to suck in a huge Wordpress.wxr/xml file and spit > out smaller files that don't trigger php/wordpress/ISP upload limits. > Each fragment needs all the preamble and postamble xml. I set up a > pseudo console using a Shoes 'para' and I define a 'puts' method that > appends the string argument to the para along with a '\n' because that's > how para works. The Shoes script calls the 'puts' with progress messages > to display. Obviously the Shoes/GUI thread can be blocked by the long > file write. It usually runs too fast to care about that. But, if the > para is in a scrollable stack and the output exceeds the visible, you > get the scrollbar displayed (as expected) but when when you scroll down > the text that caused the scroll, nothing new is is displayed although > the script is effectively finished. In Linux. Last I looked, it was OK > in Windows. > > As I mention in the comments in the script and some old emails to _why, > a 'redraw' or 'refresh' or 'flush' method is sorely missing from Shoe's > core functions. Not that big a deal for my wonky script since I now hide > the 'make little wxr's' button on success so the user as a better clue > that it's all done. I could throw up an alert instead but this isn't > about GUI design issues. > > In case you need a Raisins example, SplitWXR-0.2.rb. > > This is **not** a bug that should delay Policeman. One could easily say > I've tortured para past limits and the lack of redraw/flush/redraw is > for some future release. I agree. > > > > > -- ~devyn
On Wed, 2010-08-04 at 22:33 -0700, Devyn Cairns wrote: > 'clear' doesn't do it for you? I haven't seen your script yet, so I'm > really not sure… and I'm probably completely wrong ;] Clear and append are not the same in scrolling Console (terminal) emulation. There's an semi-documented Shoes draw() method if you really feel the need to run bat shit arm waving wild, screaming "WTF! Oh Noes! Will the flicker ever stop?!?" No it won't. ^C > > On Wed, Aug 4, 2010 at 10:10 PM, Cecil Coupe <ccoupe@cableone.net> > wrote: > On Wed, 2010-08-04 at 23:39 +0900, ashbb wrote: > > > > > I did confirm a Linux editbox/append refresh bug still > exists in > > > Policeman 1.9.1 (as it did in Raisins, and the thing > before it). > > I'd like to confirm the bug. Could you post about that into > bug list: > > http://github.com/shoes/shoes/issues > > I haven't isolated it to a simple test case that can be easily > recreated. > > The Shoes script for Policeman, you can download from my site > at > www.mvmanila.com/public - pick the SplitWxr-0.3.rb. You'll > also need a > file of data (and you need a lot of data). From the same > directory, you > can download wordpress.2010-07-25.xml (10MB of my blog) Launch > the shoes > script and select the downloaded file and press the 'make > little WXR' > button (the other defaults are fine). > > The script is designed to suck in a huge Wordpress.wxr/xml > file and spit > out smaller files that don't trigger php/wordpress/ISP upload > limits. > Each fragment needs all the preamble and postamble xml. I set > up a > pseudo console using a Shoes 'para' and I define a 'puts' > method that > appends the string argument to the para along with a '\n' > because that's > how para works. The Shoes script calls the 'puts' with > progress messages > to display. Obviously the Shoes/GUI thread can be blocked by > the long > file write. It usually runs too fast to care about that. But, > if the > para is in a scrollable stack and the output exceeds the > visible, you > get the scrollbar displayed (as expected) but when when you > scroll down > the text that caused the scroll, nothing new is is displayed > although > the script is effectively finished. In Linux. Last I looked, > it was OK > in Windows. > > As I mention in the comments in the script and some old emails > to _why, > a 'redraw' or 'refresh' or 'flush' method is sorely missing > from Shoe's > core functions. Not that big a deal for my wonky script since > I now hide > the 'make little wxr's' button on success so the user as a > better clue > that it's all done. I could throw up an alert instead but this > isn't > about GUI design issues. > > In case you need a Raisins example, SplitWXR-0.2.rb. > > This is **not** a bug that should delay Policeman. One could > easily say > I've tortured para past limits and the lack of > redraw/flush/redraw is > for some future release. I agree. > > > > > > > > -- > ~devyn
Oh, oh, I see what you mean. Would it help if Shoes checked if something was actually on the screen before asking to draw it? On Wed, Aug 4, 2010 at 10:49 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Wed, 2010-08-04 at 22:33 -0700, Devyn Cairns wrote: > > 'clear' doesn't do it for you? I haven't seen your script yet, so I'm > > really not sure… and I'm probably completely wrong ;] > > Clear and append are not the same in scrolling Console (terminal) > emulation. > > There's an semi-documented Shoes draw() method if you really feel the > need to run bat shit arm waving wild, screaming "WTF! Oh Noes! Will the > flicker ever stop?!?" No it won't. ^C > > > > > On Wed, Aug 4, 2010 at 10:10 PM, Cecil Coupe <ccoupe@cableone.net> > > wrote: > > On Wed, 2010-08-04 at 23:39 +0900, ashbb wrote: > > > > > > > I did confirm a Linux editbox/append refresh bug still > > exists in > > > > Policeman 1.9.1 (as it did in Raisins, and the thing > > before it). > > > I'd like to confirm the bug. Could you post about that into > > bug list: > > > http://github.com/shoes/shoes/issues > > > > I haven't isolated it to a simple test case that can be easily > > recreated. > > > > The Shoes script for Policeman, you can download from my site > > at > > www.mvmanila.com/public - pick the SplitWxr-0.3.rb. You'll > > also need a > > file of data (and you need a lot of data). From the same > > directory, you > > can download wordpress.2010-07-25.xml (10MB of my blog) Launch > > the shoes > > script and select the downloaded file and press the 'make > > little WXR' > > button (the other defaults are fine). > > > > The script is designed to suck in a huge Wordpress.wxr/xml > > file and spit > > out smaller files that don't trigger php/wordpress/ISP upload > > limits. > > Each fragment needs all the preamble and postamble xml. I set > > up a > > pseudo console using a Shoes 'para' and I define a 'puts' > > method that > > appends the string argument to the para along with a '\n' > > because that's > > how para works. The Shoes script calls the 'puts' with > > progress messages > > to display. Obviously the Shoes/GUI thread can be blocked by > > the long > > file write. It usually runs too fast to care about that. But, > > if the > > para is in a scrollable stack and the output exceeds the > > visible, you > > get the scrollbar displayed (as expected) but when when you > > scroll down > > the text that caused the scroll, nothing new is is displayed > > although > > the script is effectively finished. In Linux. Last I looked, > > it was OK > > in Windows. > > > > As I mention in the comments in the script and some old emails > > to _why, > > a 'redraw' or 'refresh' or 'flush' method is sorely missing > > from Shoe's > > core functions. Not that big a deal for my wonky script since > > I now hide > > the 'make little wxr's' button on success so the user as a > > better clue > > that it's all done. I could throw up an alert instead but this > > isn't > > about GUI design issues. > > > > In case you need a Raisins example, SplitWXR-0.2.rb. > > > > This is **not** a bug that should delay Policeman. One could > > easily say > > I've tortured para past limits and the lack of > > redraw/flush/redraw is > > for some future release. I agree. > > > > > > > > > > > > > > > > -- > > ~devyn > > > -- ~devyn
Every GUI has a queue or two of commands and events (draws/move/button presses) X11/GTK/Shoes probably has more than we'd like, but we work with what we have. A sync() or flush() of the queues will cause more events which can add events to the queue(s) that need to be emptied. OSX handles it, Windows handles it. Most Linux/x11/GTK can handle it. Shoes/Linux? not so well. Triggering a GUI redraw on every para append (for example) is the road to flickerville. Yet somewhere in the Shoes code base near or in animate is the magic sequence to trigger a widget redraw. On Wed, 2010-08-04 at 23:01 -0700, Devyn Cairns wrote: > Oh, oh, I see what you mean. Would it help if Shoes checked if > something was actually on the screen before asking to draw it? > > On Wed, Aug 4, 2010 at 10:49 PM, Cecil Coupe <ccoupe@cableone.net> > wrote: > On Wed, 2010-08-04 at 22:33 -0700, Devyn Cairns wrote: > > 'clear' doesn't do it for you? I haven't seen your script > yet, so I'm > > really not sure… and I'm probably completely wrong ;] > > > Clear and append are not the same in scrolling Console > (terminal) > emulation. > > There's an semi-documented Shoes draw() method if you really > feel the > need to run bat shit arm waving wild, screaming "WTF! Oh Noes! > Will the > flicker ever stop?!?" No it won't. ^C > > > > > > On Wed, Aug 4, 2010 at 10:10 PM, Cecil Coupe > <ccoupe@cableone.net> > > wrote: > > On Wed, 2010-08-04 at 23:39 +0900, ashbb wrote: > > > > > > > I did confirm a Linux editbox/append refresh bug > still > > exists in > > > > Policeman 1.9.1 (as it did in Raisins, and the > thing > > before it). > > > I'd like to confirm the bug. Could you post about > that into > > bug list: > > > http://github.com/shoes/shoes/issues > > > > I haven't isolated it to a simple test case that can > be easily > > recreated. > > > > The Shoes script for Policeman, you can download > from my site > > at > > www.mvmanila.com/public - pick the SplitWxr-0.3.rb. > You'll > > also need a > > file of data (and you need a lot of data). From the > same > > directory, you > > can download wordpress.2010-07-25.xml (10MB of my > blog) Launch > > the shoes > > script and select the downloaded file and press the > 'make > > little WXR' > > button (the other defaults are fine). > > > > The script is designed to suck in a huge > Wordpress.wxr/xml > > file and spit > > out smaller files that don't trigger > php/wordpress/ISP upload > > limits. > > Each fragment needs all the preamble and postamble > xml. I set > > up a > > pseudo console using a Shoes 'para' and I define a > 'puts' > > method that > > appends the string argument to the para along with a > '\n' > > because that's > > how para works. The Shoes script calls the 'puts' > with > > progress messages > > to display. Obviously the Shoes/GUI thread can be > blocked by > > the long > > file write. It usually runs too fast to care about > that. But, > > if the > > para is in a scrollable stack and the output exceeds > the > > visible, you > > get the scrollbar displayed (as expected) but when > when you > > scroll down > > the text that caused the scroll, nothing new is is > displayed > > although > > the script is effectively finished. In Linux. Last I > looked, > > it was OK > > in Windows. > > > > As I mention in the comments in the script and some > old emails > > to _why, > > a 'redraw' or 'refresh' or 'flush' method is sorely > missing > > from Shoe's > > core functions. Not that big a deal for my wonky > script since > > I now hide > > the 'make little wxr's' button on success so the > user as a > > better clue > > that it's all done. I could throw up an alert > instead but this > > isn't > > about GUI design issues. > > > > In case you need a Raisins example, SplitWXR-0.2.rb. > > > > This is **not** a bug that should delay Policeman. > One could > > easily say > > I've tortured para past limits and the lack of > > redraw/flush/redraw is > > for some future release. I agree. > > > > > > > > > > > > > > > > -- > > ~devyn > > > > > > > -- > ~devyn
Ah, I think I see what you mean now. So are you just using a single 'para' and appending to it? If so, maybe try using a flow of many paras? On Wed, Aug 4, 2010 at 11:57 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > Every GUI has a queue or two of commands and events (draws/move/button > presses) X11/GTK/Shoes probably has more than we'd like, but we work > with what we have. > > A sync() or flush() of the queues will cause more events which can add > events to the queue(s) that need to be emptied. OSX handles it, Windows > handles it. Most Linux/x11/GTK can handle it. Shoes/Linux? not so well. > > Triggering a GUI redraw on every para append (for example) is the road > to flickerville. Yet somewhere in the Shoes code base near or in animate > is the magic sequence to trigger a widget redraw. > > > On Wed, 2010-08-04 at 23:01 -0700, Devyn Cairns wrote: > > Oh, oh, I see what you mean. Would it help if Shoes checked if > > something was actually on the screen before asking to draw it? > > > > On Wed, Aug 4, 2010 at 10:49 PM, Cecil Coupe <ccoupe@cableone.net> > > wrote: > > On Wed, 2010-08-04 at 22:33 -0700, Devyn Cairns wrote: > > > 'clear' doesn't do it for you? I haven't seen your script > > yet, so I'm > > > really not sure… and I'm probably completely wrong ;] > > > > > > Clear and append are not the same in scrolling Console > > (terminal) > > emulation. > > > > There's an semi-documented Shoes draw() method if you really > > feel the > > need to run bat shit arm waving wild, screaming "WTF! Oh Noes! > > Will the > > flicker ever stop?!?" No it won't. ^C > > > > > > > > > > On Wed, Aug 4, 2010 at 10:10 PM, Cecil Coupe > > <ccoupe@cableone.net> > > > wrote: > > > On Wed, 2010-08-04 at 23:39 +0900, ashbb wrote: > > > > > > > > > I did confirm a Linux editbox/append refresh bug > > still > > > exists in > > > > > Policeman 1.9.1 (as it did in Raisins, and the > > thing > > > before it). > > > > I'd like to confirm the bug. Could you post about > > that into > > > bug list: > > > > http://github.com/shoes/shoes/issues > > > > > > I haven't isolated it to a simple test case that can > > be easily > > > recreated. > > > > > > The Shoes script for Policeman, you can download > > from my site > > > at > > > www.mvmanila.com/public - pick the SplitWxr-0.3.rb. > > You'll > > > also need a > > > file of data (and you need a lot of data). From the > > same > > > directory, you > > > can download wordpress.2010-07-25.xml (10MB of my > > blog) Launch > > > the shoes > > > script and select the downloaded file and press the > > 'make > > > little WXR' > > > button (the other defaults are fine). > > > > > > The script is designed to suck in a huge > > Wordpress.wxr/xml > > > file and spit > > > out smaller files that don't trigger > > php/wordpress/ISP upload > > > limits. > > > Each fragment needs all the preamble and postamble > > xml. I set > > > up a > > > pseudo console using a Shoes 'para' and I define a > > 'puts' > > > method that > > > appends the string argument to the para along with a > > '\n' > > > because that's > > > how para works. The Shoes script calls the 'puts' > > with > > > progress messages > > > to display. Obviously the Shoes/GUI thread can be > > blocked by > > > the long > > > file write. It usually runs too fast to care about > > that. But, > > > if the > > > para is in a scrollable stack and the output exceeds > > the > > > visible, you > > > get the scrollbar displayed (as expected) but when > > when you > > > scroll down > > > the text that caused the scroll, nothing new is is > > displayed > > > although > > > the script is effectively finished. In Linux. Last I > > looked, > > > it was OK > > > in Windows. > > > > > > As I mention in the comments in the script and some > > old emails > > > to _why, > > > a 'redraw' or 'refresh' or 'flush' method is sorely > > missing > > > from Shoe's > > > core functions. Not that big a deal for my wonky > > script since > > > I now hide > > > the 'make little wxr's' button on success so the > > user as a > > > better clue > > > that it's all done. I could throw up an alert > > instead but this > > > isn't > > > about GUI design issues. > > > > > > In case you need a Raisins example, SplitWXR-0.2.rb. > > > > > > This is **not** a bug that should delay Policeman. > > One could > > > easily say > > > I've tortured para past limits and the lack of > > > redraw/flush/redraw is > > > for some future release. I agree. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > ~devyn > > > > > > > > > > > > > > -- > > ~devyn > > > -- ~devyn
Alright. Read the code… and now I really don't understand why you would want to redraw there. As a workaround, does multiple paras work? On Wed, Aug 4, 2010 at 11:57 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > Every GUI has a queue or two of commands and events (draws/move/button > presses) X11/GTK/Shoes probably has more than we'd like, but we work > with what we have. > > A sync() or flush() of the queues will cause more events which can add > events to the queue(s) that need to be emptied. OSX handles it, Windows > handles it. Most Linux/x11/GTK can handle it. Shoes/Linux? not so well. > > Triggering a GUI redraw on every para append (for example) is the road > to flickerville. Yet somewhere in the Shoes code base near or in animate > is the magic sequence to trigger a widget redraw. > > > On Wed, 2010-08-04 at 23:01 -0700, Devyn Cairns wrote: > > Oh, oh, I see what you mean. Would it help if Shoes checked if > > something was actually on the screen before asking to draw it? > > > > On Wed, Aug 4, 2010 at 10:49 PM, Cecil Coupe <ccoupe@cableone.net> > > wrote: > > On Wed, 2010-08-04 at 22:33 -0700, Devyn Cairns wrote: > > > 'clear' doesn't do it for you? I haven't seen your script > > yet, so I'm > > > really not sure… and I'm probably completely wrong ;] > > > > > > Clear and append are not the same in scrolling Console > > (terminal) > > emulation. > > > > There's an semi-documented Shoes draw() method if you really > > feel the > > need to run bat shit arm waving wild, screaming "WTF! Oh Noes! > > Will the > > flicker ever stop?!?" No it won't. ^C > > > > > > > > > > On Wed, Aug 4, 2010 at 10:10 PM, Cecil Coupe > > <ccoupe@cableone.net> > > > wrote: > > > On Wed, 2010-08-04 at 23:39 +0900, ashbb wrote: > > > > > > > > > I did confirm a Linux editbox/append refresh bug > > still > > > exists in > > > > > Policeman 1.9.1 (as it did in Raisins, and the > > thing > > > before it). > > > > I'd like to confirm the bug. Could you post about > > that into > > > bug list: > > > > http://github.com/shoes/shoes/issues > > > > > > I haven't isolated it to a simple test case that can > > be easily > > > recreated. > > > > > > The Shoes script for Policeman, you can download > > from my site > > > at > > > www.mvmanila.com/public - pick the SplitWxr-0.3.rb. > > You'll > > > also need a > > > file of data (and you need a lot of data). From the > > same > > > directory, you > > > can download wordpress.2010-07-25.xml (10MB of my > > blog) Launch > > > the shoes > > > script and select the downloaded file and press the > > 'make > > > little WXR' > > > button (the other defaults are fine). > > > > > > The script is designed to suck in a huge > > Wordpress.wxr/xml > > > file and spit > > > out smaller files that don't trigger > > php/wordpress/ISP upload > > > limits. > > > Each fragment needs all the preamble and postamble > > xml. I set > > > up a > > > pseudo console using a Shoes 'para' and I define a > > 'puts' > > > method that > > > appends the string argument to the para along with a > > '\n' > > > because that's > > > how para works. The Shoes script calls the 'puts' > > with > > > progress messages > > > to display. Obviously the Shoes/GUI thread can be > > blocked by > > > the long > > > file write. It usually runs too fast to care about > > that. But, > > > if the > > > para is in a scrollable stack and the output exceeds > > the > > > visible, you > > > get the scrollbar displayed (as expected) but when > > when you > > > scroll down > > > the text that caused the scroll, nothing new is is > > displayed > > > although > > > the script is effectively finished. In Linux. Last I > > looked, > > > it was OK > > > in Windows. > > > > > > As I mention in the comments in the script and some > > old emails > > > to _why, > > > a 'redraw' or 'refresh' or 'flush' method is sorely > > missing > > > from Shoe's > > > core functions. Not that big a deal for my wonky > > script since > > > I now hide > > > the 'make little wxr's' button on success so the > > user as a > > > better clue > > > that it's all done. I could throw up an alert > > instead but this > > > isn't > > > about GUI design issues. > > > > > > In case you need a Raisins example, SplitWXR-0.2.rb. > > > > > > This is **not** a bug that should delay Policeman. > > One could > > > easily say > > > I've tortured para past limits and the lack of > > > redraw/flush/redraw is > > > for some future release. I agree. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > ~devyn > > > > > > > > > > > > > > -- > > ~devyn > > > -- ~devyn
On Thu, 2010-08-05 at 00:20 -0700, Devyn Cairns wrote: > Alright. Read the code… and now I really don't understand why you > would want to redraw there. Depends on where you are looking. Their are points in the script where I think the user would like to see progress reported in the psuedo console. Like a progress bar only textual. Back when it was written, the progressbar widget was a half backed idea. With the threading issues, it's not even quarter baked. That's not the issue. > > > As a workaround, does multiple paras work? Been there. Clunky work around and visually unappealing. Didn't work in Raisins. Para have really interesting properties that we may not fully appreciate. There is a reason for appending "\n" explicitly instead of appending it to the incoming argument string. I'm not looking for a work around, Devyn. I'm reporting a Linux bug that ashbb inquired about. I've got a decent enough user feedback mechanism in the script for the few people who will ever use the script (a declining population). If ashbb or anyone else confirms it is a Linux/Shoes bug or tries and fails to confirm it, that would be good to know. It's not a matter of how bad my code is or finding a work around. Is there a bug in shoes/linux or not? > > On Wed, Aug 4, 2010 at 11:57 PM, Cecil Coupe <ccoupe@cableone.net> > wrote: > Every GUI has a queue or two of commands and events > (draws/move/button > presses) X11/GTK/Shoes probably has more than we'd like, but > we work > with what we have. > > A sync() or flush() of the queues will cause more events which > can add > events to the queue(s) that need to be emptied. OSX handles > it, Windows > handles it. Most Linux/x11/GTK can handle it. Shoes/Linux? not > so well. > > Triggering a GUI redraw on every para append (for example) is > the road > to flickerville. Yet somewhere in the Shoes code base near or > in animate > is the magic sequence to trigger a widget redraw. > > > > On Wed, 2010-08-04 at 23:01 -0700, Devyn Cairns wrote: > > Oh, oh, I see what you mean. Would it help if Shoes checked > if > > something was actually on the screen before asking to draw > it? > > > > On Wed, Aug 4, 2010 at 10:49 PM, Cecil Coupe > <ccoupe@cableone.net> > > wrote: > > On Wed, 2010-08-04 at 22:33 -0700, Devyn Cairns > wrote: > > > 'clear' doesn't do it for you? I haven't seen your > script > > yet, so I'm > > > really not sure… and I'm probably completely > wrong ;] > > > > > > Clear and append are not the same in scrolling > Console > > (terminal) > > emulation. > > > > There's an semi-documented Shoes draw() method if > you really > > feel the > > need to run bat shit arm waving wild, screaming > "WTF! Oh Noes! > > Will the > > flicker ever stop?!?" No it won't. ^C > > > > > > > > > > On Wed, Aug 4, 2010 at 10:10 PM, Cecil Coupe > > <ccoupe@cableone.net> > > > wrote: > > > On Wed, 2010-08-04 at 23:39 +0900, ashbb > wrote: > > > > > > > > > I did confirm a Linux editbox/append > refresh bug > > still > > > exists in > > > > > Policeman 1.9.1 (as it did in Raisins, > and the > > thing > > > before it). > > > > I'd like to confirm the bug. Could you > post about > > that into > > > bug list: > > > > http://github.com/shoes/shoes/issues > > > > > > I haven't isolated it to a simple test > case that can > > be easily > > > recreated. > > > > > > The Shoes script for Policeman, you can > download > > from my site > > > at > > > www.mvmanila.com/public - pick the > SplitWxr-0.3.rb. > > You'll > > > also need a > > > file of data (and you need a lot of data). > From the > > same > > > directory, you > > > can download wordpress.2010-07-25.xml > (10MB of my > > blog) Launch > > > the shoes > > > script and select the downloaded file and > press the > > 'make > > > little WXR' > > > button (the other defaults are fine). > > > > > > The script is designed to suck in a huge > > Wordpress.wxr/xml > > > file and spit > > > out smaller files that don't trigger > > php/wordpress/ISP upload > > > limits. > > > Each fragment needs all the preamble and > postamble > > xml. I set > > > up a > > > pseudo console using a Shoes 'para' and I > define a > > 'puts' > > > method that > > > appends the string argument to the para > along with a > > '\n' > > > because that's > > > how para works. The Shoes script calls the > 'puts' > > with > > > progress messages > > > to display. Obviously the Shoes/GUI thread > can be > > blocked by > > > the long > > > file write. It usually runs too fast to > care about > > that. But, > > > if the > > > para is in a scrollable stack and the > output exceeds > > the > > > visible, you > > > get the scrollbar displayed (as expected) > but when > > when you > > > scroll down > > > the text that caused the scroll, nothing > new is is > > displayed > > > although > > > the script is effectively finished. In > Linux. Last I > > looked, > > > it was OK > > > in Windows. > > > > > > As I mention in the comments in the script > and some > > old emails > > > to _why, > > > a 'redraw' or 'refresh' or 'flush' method > is sorely > > missing > > > from Shoe's > > > core functions. Not that big a deal for my > wonky > > script since > > > I now hide > > > the 'make little wxr's' button on success > so the > > user as a > > > better clue > > > that it's all done. I could throw up an > alert > > instead but this > > > isn't > > > about GUI design issues. > > > > > > In case you need a Raisins example, > SplitWXR-0.2.rb. > > > > > > This is **not** a bug that should delay > Policeman. > > One could > > > easily say > > > I've tortured para past limits and the > lack of > > > redraw/flush/redraw is > > > for some future release. I agree. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > ~devyn > > > > > > > > > > > > > > -- > > ~devyn > > > > > > > -- > ~devyn >
Hi Cecil, Devyn and folks, I did a little bit revising Cecil's SplitWXR-0.3.rb. Download from here: http://gist.github.com/509697 I confirmed that it worked well on Windows XP and Linux (on VirtualBox Windows) with my latest Shoes Policeman. I got output-files, but I'm not sure their contents are correct or not, though... So, try to confirm on your platform. BTW. Thank you, Cecil. We've found the following four points: - `class Shoes::Para` doesn't work as we expect. Workaround is `Shoes::Para.class_eval`. - `self.contents << str` is not repainted immediately. But `self.text += str` is repainted immediately. I think this is the spec of Shoes. - String#each is not available in Ruby 1.9.1 Needed to add `ln = ln.force_encoding 'UTF-8'`. But I don't know why. This is a monky patch. :-P - background object is not expand in scrollable slot. I'm not sure this is spec or not. Workaround is putting rect object under the slot. Okay now, please discuss about the above points. Do you think they are bugs or need to revise Shoes or ...? ;-) Let's enjoy improving Shoes! ashbb
On Thu, 2010-08-05 at 22:13 +0900, ashbb wrote: > Hi Cecil, Devyn and folks, > > I did a little bit revising Cecil's SplitWXR-0.3.rb. > Download from here: http://gist.github.com/509697 > > I confirmed that it worked well on Windows XP and Linux (on VirtualBox > Windows) with my latest Shoes Policeman. I got output-files, but I'm > not sure their contents are correct or not, though... > > So, try to confirm on your platform. > Works fine on my Linux - thank you for all the debugging you did. > BTW. Thank you, Cecil. We've found the following four points: > > - `class Shoes::Para` doesn't work as we expect. > Workaround is `Shoes::Para.class_eval`. Not a Shoes bug. A caution about fooling with Shoes internals if your don't know what you're doing. Should probably note it somewhere in the Wiki section about Shoes internals. > > - `self.contents << str` is not repainted immediately. > But `self.text += str` is repainted immediately. > I think this is the spec of Shoes. Nice catch! > > - String#each is not available in Ruby 1.9.1 > Needed to add `ln = ln.force_encoding 'UTF-8'`. > But I don't know why. This is a monky patch. :-P That's my error. I didn't put up the version that opens the files in ASCII-8BIT and the input file you used was relatively clean utf-8. Perhaps your OS/system default is not UTF-8? > > - background object is not expand in scrollable slot. > I'm not sure this is spec or not. > Workaround is putting rect object under the slot. Certainly not a bug worth delaying Policeman for. Should this be entered into the issues (and create a test case) or just too obscure to worry about? Thanks for the education, ashbb!
On Thu, Aug 5, 2010 at 7:16 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Thu, 2010-08-05 at 22:13 +0900, ashbb wrote: > > Hi Cecil, Devyn and folks, > > > > I did a little bit revising Cecil's SplitWXR-0.3.rb. > > Download from here: http://gist.github.com/509697 > > > > I confirmed that it worked well on Windows XP and Linux (on VirtualBox > > Windows) with my latest Shoes Policeman. I got output-files, but I'm > > not sure their contents are correct or not, though... > > > > So, try to confirm on your platform. > > > Works fine on my Linux - thank you for all the debugging you did. > > > BTW. Thank you, Cecil. We've found the following four points: > > > > - `class Shoes::Para` doesn't work as we expect. > > Workaround is `Shoes::Para.class_eval`. > > Not a Shoes bug. A caution about fooling with Shoes internals if your > don't know what you're doing. Should probably note it somewhere in the > Wiki section about Shoes internals. > > > > > - `self.contents << str` is not repainted immediately. > > But `self.text += str` is repainted immediately. > > I think this is the spec of Shoes. > > Nice catch! > > > > - String#each is not available in Ruby 1.9.1 > > Needed to add `ln = ln.force_encoding 'UTF-8'`. > > But I don't know why. This is a monky patch. :-P > > That's my error. I didn't put up the version that opens the files in > ASCII-8BIT and the input file you used was relatively clean utf-8. > Perhaps your OS/system default is not UTF-8? > Instead of passing ASCII-8BIT to File.open, have you tried just using an encoding comment set to ASCII-8BIT? # encoding: ASCII-8BIT I think this should work, but I'm not sure. > > > > - background object is not expand in scrollable slot. > > I'm not sure this is spec or not. > > Workaround is putting rect object under the slot. > > Certainly not a bug worth delaying Policeman for. Should this be entered > into the issues (and create a test case) or just too obscure to worry > about? > I've experienced this before, so it's definitely not obscure. I think that backgrounds should be fixed in position relative to the slot they're in—to not scroll at all. What do you think? > > Thanks for the education, ashbb! > > > -- ~devyn
On Thu, 2010-08-05 at 20:12 -0700, Devyn Cairns wrote: > Instead of passing ASCII-8BIT to File.open, have you tried just using > an encoding comment set to ASCII-8BIT? > > # encoding: ASCII-8BIT No, I haven't and it would be a minor PITA for me to try, but you can. I don't like interpreters that look into my comments for special instructions. Comments should be comments. > > I think this should work, but I'm not sure. > > > > - background object is not expand in scrollable slot. > > I'm not sure this is spec or not. > > Workaround is putting rect object under the slot. > > I've experienced this before, so it's definitely not obscure. I think > that backgrounds should be fixed in position relative to the slot > they're in—to not scroll at all. What do you think? A simple color choice background on an explicitly declared scrollable slot should fill in the empty space from scrolling (user or script initiated) with the background. An image background is another matter. It shouldn't expand or contract unless directed too do so. IMO
On Thu, Aug 5, 2010 at 11:49 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Thu, 2010-08-05 at 20:12 -0700, Devyn Cairns wrote: > > Instead of passing ASCII-8BIT to File.open, have you tried just using > > an encoding comment set to ASCII-8BIT? > > > > # encoding: ASCII-8BIT > No, I haven't and it would be a minor PITA for me to try, but you can. I > don't like interpreters that look into my comments for special > instructions. Comments should be comments. > > > > I think this should work, but I'm not sure. > > > > > > - background object is not expand in scrollable slot. > > > I'm not sure this is spec or not. > > > Workaround is putting rect object under the slot. > > > > I've experienced this before, so it's definitely not obscure. I think > > that backgrounds should be fixed in position relative to the slot > > they're in—to not scroll at all. What do you think? > > A simple color choice background on an explicitly declared scrollable > slot should fill in the empty space from scrolling (user or script > initiated) with the background. An image background is another matter. > It shouldn't expand or contract unless directed too do so. IMO If we just made them fixed in place, though… then when you scroll, the content moves but the background does not. If you wanted the background to move, you could just put another slot at an absolute position with that background inside the slot. Right? -- ~devyn
On Fri, 2010-08-06 at 12:07 -0700, Devyn Cairns wrote: > > If we just made them fixed in place, though… then when you scroll, the > content moves but the background does not. If you wanted the > background to move, you could just put another slot at an absolute > position with that background inside the slot. Right? I've got a short test script below that demonstrates the behavior. The question isn't how to fix it with additional Shoes layout. Shoes.app :width => 450, :height => 420 do @s = stack :width => 1.0, :margin_right => 20, :height => 200, :scroll => true do background "#555" end button "Draw" do 10.times {|i| @s.append {para "Line #{i+1}"}} end end Press the draw button and scroll to the end. Is this the expected behavior of a scrolled background? Note, I'm not saying this is an important issue. Slots are mostly like layout managers in other GUI tool kits, Until you add trigger the scroll bar and then it takes on some drawing behavior of an element.
Every bug should get an issue, even if It's obscure. It'll just sit at the bottom of the pile for a while, then. But better to have it written down. On Aug 5, 2010 7:16 PM, "Cecil Coupe" <ccoupe@cableone.net> wrote: > On Thu, 2010-08-05 at 22:13 +0900, ashbb wrote: >> Hi Cecil, Devyn and folks, >> >> I did a little bit revising Cecil's SplitWXR-0.3.rb. >> Download from here: http://gist.github.com/509697 >> >> I confirmed that it worked well on Windows XP and Linux (on VirtualBox >> Windows) with my latest Shoes Policeman. I got output-files, but I'm >> not sure their contents are correct or not, though... >> >> So, try to confirm on your platform. >> > Works fine on my Linux - thank you for all the debugging you did. > >> BTW. Thank you, Cecil. We've found the following four points: >> >> - `class Shoes::Para` doesn't work as we expect. >> Workaround is `Shoes::Para.class_eval`. > > Not a Shoes bug. A caution about fooling with Shoes internals if your > don't know what you're doing. Should probably note it somewhere in the > Wiki section about Shoes internals. > >> >> - `self.contents << str` is not repainted immediately. >> But `self.text += str` is repainted immediately. >> I think this is the spec of Shoes. > > Nice catch! >> >> - String#each is not available in Ruby 1.9.1 >> Needed to add `ln = ln.force_encoding 'UTF-8'`. >> But I don't know why. This is a monky patch. :-P > > That's my error. I didn't put up the version that opens the files in > ASCII-8BIT and the input file you used was relatively clean utf-8. > Perhaps your OS/system default is not UTF-8? >> >> - background object is not expand in scrollable slot. >> I'm not sure this is spec or not. >> Workaround is putting rect object under the slot. > > Certainly not a bug worth delaying Policeman for. Should this be entered > into the issues (and create a test case) or just too obscure to worry > about? > > Thanks for the education, ashbb! > >
On Thu, 2010-08-05 at 23:14 -0400, Steve Klabnik wrote: > Every bug should get an issue, even if It's obscure. It'll just sit at > the bottom of the pile for a while, then. But better to have it > written down I knew you were going to say that ;^). Issue filed, quite weaselly, IMO. But it's there.
On Thu, Aug 5, 2010 at 6:13 AM, ashbb <ashbbb@gmail.com> wrote: > Hi Cecil, Devyn and folks, > > I did a little bit revising Cecil's SplitWXR-0.3.rb. > Download from here: http://gist.github.com/509697 > > I confirmed that it worked well on Windows XP and Linux (on VirtualBox > Windows) with my latest Shoes Policeman. I got output-files, but I'm not > sure their contents are correct or not, though... > > So, try to confirm on your platform. > > BTW. Thank you, Cecil. We've found the following four points: > > - `class Shoes::Para` doesn't work as we expect. > Workaround is `Shoes::Para.class_eval`. > > - `self.contents << str` is not repainted immediately. > But `self.text += str` is repainted immediately. > I think this is the spec of Shoes. > > - String#each is not available in Ruby 1.9.1 > Needed to add `ln = ln.force_encoding 'UTF-8'`. > But I don't know why. This is a monky patch. :-P > instead of that, did you try putting # encoding: ASCII-8BIT at the top of the file? > > - background object is not expand in scrollable slot. > I'm not sure this is spec or not. > Workaround is putting rect object under the slot. > > Okay now, please discuss about the above points. > Do you think they are bugs or need to revise Shoes or ...? ;-) > > Let's enjoy improving Shoes! > ashbb > > -- ~devyn
On Tue, 2010-08-03 at 12:49 +0530, Martin DeMello wrote: > On Tue, Aug 3, 2010 at 7:41 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > > > > It's long story. I'll try to keep it short. I've got a Shoes script > > that reads export files from Wordpress blogs (so it's a php download of > > a mysql DB) dressed up to look like it's XML. It's never been valid XML > > so you have to parse it as lines and strings and regexps. It's also very > > likely to have characters that aren't US-ASCII or UTF-8. in 1.8.7 you do > > string ops on it through. In 1.9.1 it throws an exception since the data > > doesn't pass any encoding that I know of. > > That's ideally what ASCII-8BIT is for. > http://yehudakatz.com/2010/05/17/encodings-unabridged/ is a good read > on the topic. > > martin Thank you Martin! Yes, it is worth reading. I'm now able to avoid ruby encoding exceptions and I am consistently getting the same error from two different input files, Believe me, that's progress. Obviously, there is some other 1.9.1 change going on (no method 'each' for String???). I should have recognized the symptoms of two errors working together. Did 1.9.1 change the behavior of each and each_line? I'll google. Thanks
On Wed, Aug 4, 2010 at 8:31 AM, Cecil Coupe <ccoupe@cableone.net> wrote: > > Did 1.9.1 change the behavior of each and each_line? I'll google. Yep, there's no longer a String#each. Use #each_char, #each_byte and #each_line depending on what you want. See http://blog.grayproductions.net/articles/ruby_19s_string martin
Just a quick reply (because I'm at an onsen ryokan ... not exactly the best internet, nor what I want to be doing at the moment ;) but the reason I expect threading issues to be fixed in 1.9.2 is that Rails doesn't support 1.9.1 and does support 1.9.2, because of them. Oh, and the rolling release vs kernel stuff? I don't remember because I haven't updated my Arch box in a bit, but I'd imagine it's just like any other software: when a new version comes out, it gets released. On 8/2/10, Cecil Coupe <ccoupe@cableone.net> wrote: > On Mon, 2010-08-02 at 12:48 -0700, Devyn Cairns wrote: > > >> >> >> I still don't see the validity of your UTF-8 complaints—I'm going to >> need some evidence to back that up ;] > > It's long story. I'll try to keep it short. I've got a Shoes script > that reads export files from Wordpress blogs (so it's a php download of > a mysql DB) dressed up to look like it's XML. It's never been valid XML > so you have to parse it as lines and strings and regexps. It's also very > likely to have characters that aren't US-ASCII or UTF-8. in 1.8.7 you do > string ops on it through. In 1.9.1 it throws an exception since the data > doesn't pass any encoding that I know of. > > The user could clean up the data, one error at a time, download, shoes > script run (and repeat until all errors are gone). Not user friendly. As > long as Raisins and 1.8.7 is available, it's not a big problem. If the > user upgrades Wordpress to the latest (3.0), there are new export > options which negate the need to run my Shoes script, so it's not a big > problem (as a Shoes developer, the app need is now close to nil). > > I've got another set of ruby scripts that also have to deal with dodgey > characters downloaded from from the net. Those are 100% certain to have > character set issues. Yes, I could write a C program to copy the file > replacing the characters with ones that are correct. I can't process the > originals in Ruby 1.9.1. Catch-22's just annoys me. On the other hand, > you wouldn't believe the destruction you can cause by changing MySQL's > character set -- Thank you Apple MySQL team, but that was long ago and I > had some blame in that mess. > >> >> (4) Black Helicopters funded by the Progressive Pythonista >> Assimilation >> Movement are hovering over Japan with disrupter ray guns set >> to "Rolling >> Release". :^) >> >> >> This one made me laugh ;] > Good. It was supposed to. > > It's all good. > > > >
On Mon, 2010-08-02 at 22:19 -0400, Steve Klabnik wrote: > Just a quick reply (because I'm at an onsen ryokan ... not exactly the > best internet, nor what I want to be doing at the moment ;) but the > reason I expect threading issues to be fixed in 1.9.2 is that Rails > doesn't support 1.9.1 and does support 1.9.2, because of them. Really? Rails folks couldn't figure it out with 1.9.1? I didn't know that. Supports my speculation (3) the Ruby mothership made some serious boo-boos with 1.9.1.
A small note, Rails 2 does support 1.9.1, but Rails 3 does not. I knew there was some smaller detail in there. On 8/2/10, Cecil Coupe <ccoupe@cableone.net> wrote: > On Mon, 2010-08-02 at 22:19 -0400, Steve Klabnik wrote: >> Just a quick reply (because I'm at an onsen ryokan ... not exactly the >> best internet, nor what I want to be doing at the moment ;) but the >> reason I expect threading issues to be fixed in 1.9.2 is that Rails >> doesn't support 1.9.1 and does support 1.9.2, because of them. > > Really? Rails folks couldn't figure it out with 1.9.1? I didn't know > that. Supports my speculation (3) the Ruby mothership made some serious > boo-boos with 1.9.1. > >
Hi Yiling, I have less of a sense of Linux. But I'm building Shoes for Linux on Windows VirtualBox. This is a tiny note: http://github.com/ashbb/shoes_hack_note/blob/master/md/hack026.md As Cecil mentioned, you need to install Ruby 1.9.1. Hope this helps, ashbb
Who *is* the to go-to volunteer that is fixing up the wiki for the Policeman release? Anyone? On Sun, 2010-08-01 at 12:51 +0900, ashbb wrote: > Hi Yiling, > > I have less of a sense of Linux. But I'm building Shoes for Linux on > Windows VirtualBox. This is a tiny note: > http://github.com/ashbb/shoes_hack_note/blob/master/md/hack026.md > > As Cecil mentioned, you need to install Ruby 1.9.1. > > Hope this helps, > ashbb
> > Who *is* the to go-to volunteer that is fixing up the wiki for the Policeman release? Anyone? I'm planning on doing a bunch of work on the Wiki when I return from Japan. I think I'll put the 1.8.7 conditionals back in binject.c so Shoes works for everybody. I can't fix Ubuntu but I can fix Shoes. Shoes _does_ work for everybody. Everybody who wants to use shoes should still be using Raisins, not compiling Policeman. And if they're compiling Policeman, they can get Ruby 1.9 on their system. I'm really opposed to a dual 1.8/1.9 shoes, because that's going to be absolute hell to support. We've already got a project across 6 OSes already, if we try to do both Rubies, then that explodes to 12.
On Sun, 2010-08-01 at 20:17 -0400, Steve Klabnik wrote: > Who *is* the to go-to volunteer that is fixing up the wiki for > the > Policeman release? Anyone? > > > I'm planning on doing a bunch of work on the Wiki when I return from > Japan. > > > I think I'll put the 1.8.7 conditionals back in binject.c so > Shoes works > for everybody. I can't fix Ubuntu but I can fix Shoes. > > > Shoes _does_ work for everybody. Everybody who wants to use shoes > should still be using Raisins, not compiling Policeman. And if they're > compiling Policeman, they can get Ruby 1.9 on their system. Just a nit pick (see below), but Linux users of Shoes have to build from source. There's two many variations to have one executable to rule all the penguins. > > > I'm really opposed to a dual 1.8/1.9 shoes, because that's going to be > absolute hell to support. We've already got a project across 6 OSes > already, if we try to do both Rubies, then that explodes to 12. > This is a valid point, particularly when only two OS account for the bulk of the user community installs and neither of them have to compile. shoes. On the other hand, For a C programmer, a few #ifdefs in one file (and some Rakefile love) is no big deal to support compatibility for a few more years until 1.8.7 and and 1.9.1 get replaced in the slow distribution upgrades.
> > > Just a nit pick (see below), but Linux users of Shoes have to build from > source. There's two many variations to have one executable to rule all > the penguins. > Oh, I just clicked a shoes2.run file. I'm not as up on the latest Linux stuff, though. > This is a valid point, particularly when only two OS account for the > bulk of the user community installs and neither of them have to compile. > shoes. > It's really 6 OSes - XP, Vista, 7, OSX10.{5,6}. > On the other hand, For a C programmer, a few #ifdefs in one file (and > some Rakefile love) is no big deal to support compatibility for a few > more years until 1.8.7 and and 1.9.1 get replaced in the slow > distribution upgrades. > The real problem is the code that runs within Shoes itself. What happens when someone tries to write some 1.9 code and they're using a 1.8 shoes? How do we plan on answering that question in support? Do we have a zillion different binaries for people to use? A few #ifdefs isn't a big deal, you're right. I'm worried about the users.
On Sun, 2010-08-01 at 21:10 -0400, Steve Klabnik wrote: > > > Just a nit pick (see below), but Linux users of Shoes have to > build from > source. There's two many variations to have one executable to > rule all > the penguins. > > > Oh, I just clicked a shoes2.run file. I'm not as up on the latest > Linux stuff, though. 32 bit or 64? PPC? ARM? There are projects that provide a long list of binaries for various distributions of Linux. We can't possibly build binaries for all Linux folk who might arrive, nor can we expect that our code will be blessed into major distributions. Linux users build from source unless their package manager happens to have an (often old) version. > > This is a valid point, particularly when only two OS account > for the > bulk of the user community installs and neither of them have > to compile. > shoes. > > > It's really 6 OSes - XP, Vista, 7, OSX10.{5,6}. Separate exe's for XP, Vista, Win7? Really? Separate dmgs for 10.5 and 10.6? I don't think pack.rb the has those choices. Nor does the download server. We need to test against 5 plus some scary number of Linux creatures. Come to t > > On the other hand, For a C programmer, a few #ifdefs in one > file (and > some Rakefile love) is no big deal to support compatibility > for a few > more years until 1.8.7 and and 1.9.1 get replaced in the slow > distribution upgrades. > > The real problem is the code that runs within Shoes itself. What > happens when someone tries to write some 1.9 code and they're using a > 1.8 shoes? How do we plan on answering that question in support? Do we > have a zillion different binaries for people to use? Understood. That's why we set the bar at 1.9.1. We just forgot to change the Ubuntu build instructions to have separate instructions for Raisins and current (policeman)
On Sun, Aug 1, 2010 at 7:41 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Sun, 2010-08-01 at 21:10 -0400, Steve Klabnik wrote: > > > > > > Just a nit pick (see below), but Linux users of Shoes have to > > build from > > source. There's two many variations to have one executable to > > rule all > > the penguins. > > > > > > Oh, I just clicked a shoes2.run file. I'm not as up on the latest > > Linux stuff, though. > > 32 bit or 64? PPC? ARM? There are projects that provide a long list of > binaries for various distributions of Linux. We can't possibly build > binaries for all Linux folk who might arrive, nor can we expect that our > code will be blessed into major distributions. Linux users build from > source unless their package manager happens to have an (often old) > version. > > > > This is a valid point, particularly when only two OS account > > for the > > bulk of the user community installs and neither of them have > > to compile. > > shoes. > > > > > > It's really 6 OSes - XP, Vista, 7, OSX10.{5,6}. > Separate exe's for XP, Vista, Win7? Really? Separate dmgs for 10.5 and > 10.6? I don't think pack.rb the has those choices. Nor does the download > server. > We'll probably only need one EXE for modern versions of Windows, two DMGs (10.4/10.5 and 10.5/10.6)—although we might be able to get one only if the API likes us ;], and a ridiculously simple to install source distribution for everyone else. > > We need to test against 5 plus some scary number of Linux creatures. > Come to t > > > > On the other hand, For a C programmer, a few #ifdefs in one > > file (and > > some Rakefile love) is no big deal to support compatibility > > for a few > > more years until 1.8.7 and and 1.9.1 get replaced in the slow > > distribution upgrades. > > > > The real problem is the code that runs within Shoes itself. What > > happens when someone tries to write some 1.9 code and they're using a > > 1.8 shoes? How do we plan on answering that question in support? Do we > > have a zillion different binaries for people to use? > > Understood. That's why we set the bar at 1.9.1. We just forgot to change > the Ubuntu build instructions to have separate instructions for Raisins > and current (policeman) > > > > -- ~devyn
On Sun, 2010-08-01 at 20:52 -0700, Devyn Cairns wrote: > > It's really 6 OSes - XP, Vista, 7, OSX10.{5,6}. > > Separate exe's for XP, Vista, Win7? Really? Separate dmgs for > 10.5 and > 10.6? I don't think pack.rb the has those choices. Nor does > the download > server. > > > We'll probably only need one EXE for modern versions of Windows, two > DMGs (10.4/10.5 and 10.5/10.6)—although we might be able to get one > only if the API likes us ;], and a ridiculously simple to install > source distribution for everyone else. > Watch me go off topic. This is a problem we need to talk about (consensus towards?). The website doesn't offer fine grained downloads. Pack.rb and the website just knows about [Raisins|Policeman] and [win32|osx|linux]. If we have to provide osx32 and osx64 binaries, then we could provide (in theory) Linux32 and Linux64 and LinuxPPC binaries for download when a exe/dmg/run asks for it.I'm not saying an 'arch' modifier is bad but it's a bit of a problem for users who just want to package up their Shoes script for every variation that downloads it. For me, that's the major selling point of Shoes over other cross platform tool kits and graphical DSLs, enough to keep me involved. My/your/someones script in an tidy exe/dmg/run that downloads the version of Ruby/Shoes needed. The alternative would be to make it a two step process. First, manually download and install the version of Shoes to match your platform from the shoes website that has many, many binary versions to choose from Then download and run the shy (or text file). On the upside, we could delete pack.rb and all the code that packages exe, dmgs and .runs. Or we could get hard case and cut out the inconvenient edge cases. OSX 10.5 ? Pay your Apple tax and upgrade to Intel 10.6 64bit XP? Vista? Who cares about those old things, Win 7 64 bit for you. Linux? we don't care about Linux, we're mainstream and we only look forward! I really don't have a dog in this fight. My scripts in the wild aren't going to work with 1.9.1 (it's not Ruby's fault, Shoes or mine). I do not not care how this is solved. I really don't. I'm only hanging around because I said I'd help the Linux folks. They helped me, I help them when I can. I've seen this cross platform installer issue more often than I care to repeat. For a brief moment, _why solved it and that was freaking cool! But that was then and things aren't the same. My apologies for going meta-off-topic, stealing the thread and harshing the vibe on the mailing list. I care about cross platform, maybe too much. --Cecil
On Sun, Aug 1, 2010 at 11:16 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Sun, 2010-08-01 at 20:52 -0700, Devyn Cairns wrote: > > > It's really 6 OSes - XP, Vista, 7, OSX10.{5,6}. > > > > Separate exe's for XP, Vista, Win7? Really? Separate dmgs for > > 10.5 and > > 10.6? I don't think pack.rb the has those choices. Nor does > > the download > > server. > > > > > > We'll probably only need one EXE for modern versions of Windows, two > > DMGs (10.4/10.5 and 10.5/10.6)—although we might be able to get one > > only if the API likes us ;], and a ridiculously simple to install > > source distribution for everyone else. > > > Watch me go off topic. > > This is a problem we need to talk about (consensus towards?). The > website doesn't offer fine grained downloads. Pack.rb and the website > just knows about [Raisins|Policeman] and [win32|osx|linux]. If we have > to provide osx32 and osx64 binaries, then we could provide (in theory) > Linux32 and Linux64 and LinuxPPC binaries for download when a > exe/dmg/run asks for it.I'm not saying an 'arch' modifier is bad but > it's a bit of a problem for users who just want to package up their > Shoes script for every variation that downloads it. > > For me, that's the major selling point of Shoes over other cross > platform tool kits and graphical DSLs, enough to keep me involved. > My/your/someones script in an tidy exe/dmg/run that downloads the > version of Ruby/Shoes needed. > > The alternative would be to make it a two step process. First, manually > download and install the version of Shoes to match your platform from > the shoes website that has many, many binary versions to choose from > Then download and run the shy (or text file). On the upside, we could > delete pack.rb and all the code that packages exe, dmgs and .runs. > > Or we could get hard case and cut out the inconvenient edge cases. OSX > 10.5 ? Pay your Apple tax and upgrade to Intel 10.6 64bit XP? Vista? Who > cares about those old things, Win 7 64 bit for you. Linux? we don't care > about Linux, we're mainstream and we only look forward! > > I really don't have a dog in this fight. My scripts in the wild aren't > going to work with 1.9.1 (it's not Ruby's fault, Shoes or mine). I do > not not care how this is solved. I really don't. I'm only hanging around > because I said I'd help the Linux folks. They helped me, I help them > when I can. I've seen this cross platform installer issue more often > than I care to repeat. For a brief moment, _why solved it and that was > freaking cool! But that was then and things aren't the same. > > My apologies for going meta-off-topic, stealing the thread and harshing > the vibe on the mailing list. I care about cross platform, maybe too > much. > Don't get me wrong, I'm a cross-platform advocate too. I've run Windows XP, then Ubuntu, then some other crazy distros until I met Arch, and now I have a MacBook. It's important to me :] But I think you could probably tone it down just a little? > --Cecil > > -- ~devyn
I care about cross platform too. And we should come to consensus over this. When I said three different Windows OSes, there are issues that crop up in each particular version of Windows. I'm unsure if they can/are already unified, but the window flickering issue, for example, needs three different things on XP/Vista/7. On the OSX side, the biggest one is 64 bit vs 32... I can't figure out how to compile 32 bit Shoes on Snow Leopard. I can't figure out how to get 32 bit shoes (at least the one build that we have) to run on Snow Leopard. And Snow Leopard itself had tons of changes under the hood, so everything should be okay going forward. I think what's best for Linux is to support building from source only for now, possibly making a .deb and .rpm in the future. Anyway, I come back from Japan tomorrow. I'll still be on vacation until Sunday, but at least I'll be able to check my email. What do you guys think about this: I'll check out some code, come up with a proposal for all of this, and post it to the list by tomorrow night. Then we can hash out/argue over the details, and get everything wrapped up. We're almost done, it's just these last little few things... I plan on seriously busting my ass to get Shoes 3 and Hackety out on Whyday, and I think we're going to be able to do it. But I think it'd be more constructive to do this over an actual document with a plan, rather than a bunch of scattered emails. Sound good? On 8/2/10, Devyn Cairns <devyn.cairns@gmail.com> wrote: > On Sun, Aug 1, 2010 at 11:16 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > >> On Sun, 2010-08-01 at 20:52 -0700, Devyn Cairns wrote: >> > > It's really 6 OSes - XP, Vista, 7, OSX10.{5,6}. >> > >> > Separate exe's for XP, Vista, Win7? Really? Separate dmgs for >> > 10.5 and >> > 10.6? I don't think pack.rb the has those choices. Nor does >> > the download >> > server. >> > >> > >> > We'll probably only need one EXE for modern versions of Windows, two >> > DMGs (10.4/10.5 and 10.5/10.6)—although we might be able to get one >> > only if the API likes us ;], and a ridiculously simple to install >> > source distribution for everyone else. >> > >> Watch me go off topic. >> >> This is a problem we need to talk about (consensus towards?). The >> website doesn't offer fine grained downloads. Pack.rb and the website >> just knows about [Raisins|Policeman] and [win32|osx|linux]. If we have >> to provide osx32 and osx64 binaries, then we could provide (in theory) >> Linux32 and Linux64 and LinuxPPC binaries for download when a >> exe/dmg/run asks for it.I'm not saying an 'arch' modifier is bad but >> it's a bit of a problem for users who just want to package up their >> Shoes script for every variation that downloads it. >> >> For me, that's the major selling point of Shoes over other cross >> platform tool kits and graphical DSLs, enough to keep me involved. >> My/your/someones script in an tidy exe/dmg/run that downloads the >> version of Ruby/Shoes needed. >> >> The alternative would be to make it a two step process. First, manually >> download and install the version of Shoes to match your platform from >> the shoes website that has many, many binary versions to choose from >> Then download and run the shy (or text file). On the upside, we could >> delete pack.rb and all the code that packages exe, dmgs and .runs. >> >> Or we could get hard case and cut out the inconvenient edge cases. OSX >> 10.5 ? Pay your Apple tax and upgrade to Intel 10.6 64bit XP? Vista? Who >> cares about those old things, Win 7 64 bit for you. Linux? we don't care >> about Linux, we're mainstream and we only look forward! >> >> I really don't have a dog in this fight. My scripts in the wild aren't >> going to work with 1.9.1 (it's not Ruby's fault, Shoes or mine). I do >> not not care how this is solved. I really don't. I'm only hanging around >> because I said I'd help the Linux folks. They helped me, I help them >> when I can. I've seen this cross platform installer issue more often >> than I care to repeat. For a brief moment, _why solved it and that was >> freaking cool! But that was then and things aren't the same. >> >> My apologies for going meta-off-topic, stealing the thread and harshing >> the vibe on the mailing list. I care about cross platform, maybe too >> much. >> > > Don't get me wrong, I'm a cross-platform advocate too. I've run Windows XP, > then Ubuntu, then some other crazy distros until I met Arch, and now I have > a MacBook. It's important to me :] > > But I think you could probably tone it down just a little? > > >> --Cecil >> >> > > > -- > ~devyn >
> We're almost done, it's just these last little > few things... I plan on seriously busting my > ass to get Shoes 3 and Hackety out on Whyday, > and I think we're going to be able to do it. > But I think it'd be more constructive to do > this over an actual document with a plan, > rather than a bunch of scattered emails. > > Sound good? Awesome! I'd love to help you. What can I do for you? ashbb
On Mon, 2010-08-02 at 22:29 -0400, Steve Klabnik wrote: > I care about cross platform too. And we should come to consensus over this. > > When I said three different Windows OSes, there are issues that crop > up in each particular version of Windows. I'm unsure if they can/are > already unified, but the window flickering issue, for example, needs > three different things on XP/Vista/7. The power of #ifdef (just joking, Steve) > > On the OSX side, the biggest one is 64 bit vs 32... I can't figure out > how to compile 32 bit Shoes on Snow Leopard. I can't figure out how to > get 32 bit shoes (at least the one build that we have) to run on Snow > Leopard. And Snow Leopard itself had tons of changes under the hood, > so everything should be okay going forward. I suggest that 10.6 is the 'latest' version, the one that gets used for packaging. If someone can compile Policeman from current source on 10.5, they can make it available on a download page at the website. If, for some reason there has to be Win7 exe that differs from the XP/Vista exe then it too would be 'current' for packing purposes. > > I think what's best for Linux is to support building from source only > for now, possibly making a .deb and .rpm in the future. Put up a intel 32 bit run (ashbb has one) under latest and label it as not appropriate for all Linux. Or remove Linux as an option in the pack.rb code. Then on the website, next to source download, and the 10.5 download we can put the 10.5 PPC Policeman and the X64_amd_Linux and any other variation that can be built from the Policeman source for downloading (along with name of the person who built it in case there questions. .deb and .rpm can wait a long time, IMO. Perhaps after the 1.9.2 goodness rains down from the skies? > > > Anyway, I come back from Japan tomorrow. I'll still be on vacation > until Sunday, but at least I'll be able to check my email. What do you > guys think about this: I'll check out some code, come up with a > proposal for all of this, and post it to the list by tomorrow night. > Then we can hash out/argue over the details, and get everything > wrapped up. We're almost done, it's just these last little few > things... I plan on seriously busting my ass to get Shoes 3 and > Hackety out on Whyday, and I think we're going to be able to do it. > But I think it'd be more constructive to do this over an actual > document with a plan, rather than a bunch of scattered emails. > > Sound good? Sounds good to me.
On Mon, Aug 2, 2010 at 8:20 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Mon, 2010-08-02 at 22:29 -0400, Steve Klabnik wrote: > > I care about cross platform too. And we should come to consensus over > this. > > > > When I said three different Windows OSes, there are issues that crop > > up in each particular version of Windows. I'm unsure if they can/are > > already unified, but the window flickering issue, for example, needs > > three different things on XP/Vista/7. > The power of #ifdef (just joking, Steve) > > > > On the OSX side, the biggest one is 64 bit vs 32... I can't figure out > > how to compile 32 bit Shoes on Snow Leopard. I can't figure out how to > > get 32 bit shoes (at least the one build that we have) to run on Snow > > Leopard. And Snow Leopard itself had tons of changes under the hood, > > so everything should be okay going forward. > I suggest that 10.6 is the 'latest' version, the one that gets used for > packaging. If someone can compile Policeman from current source on 10.5, > they can make it available on a download page at the website. Hey, Micah, we need you ;] (he runs 32-bit 10.5) IIRC, he was having some issues with building it though. > If, for > some reason there has to be Win7 exe that differs from the XP/Vista exe > then it too would be 'current' for packing purposes. > > > > I think what's best for Linux is to support building from source only > > for now, possibly making a .deb and .rpm in the future. > > Put up a intel 32 bit run (ashbb has one) under latest and label it as > not appropriate for all Linux. Or remove Linux as an option in the > pack.rb code. Then on the website, next to source download, and the 10.5 > download we can put the 10.5 PPC Policeman and the X64_amd_Linux and any > other variation that can be built from the Policeman source for > downloading (along with name of the person who built it in case there > questions. > Why can't the stub .run just be a shell script (ie, portable) that automatically checks the system type (uname) and consults the server to find a build of Shoes that's compatible? > > .deb and .rpm can wait a long time, IMO. Perhaps after the 1.9.2 > goodness rains down from the skies? > ;] > > > > > > Anyway, I come back from Japan tomorrow. I'll still be on vacation > > until Sunday, but at least I'll be able to check my email. What do you > > guys think about this: I'll check out some code, come up with a > > proposal for all of this, and post it to the list by tomorrow night. > > Then we can hash out/argue over the details, and get everything > > wrapped up. We're almost done, it's just these last little few > > things... I plan on seriously busting my ass to get Shoes 3 and > > Hackety out on Whyday, and I think we're going to be able to do it. > > But I think it'd be more constructive to do this over an actual > > document with a plan, rather than a bunch of scattered emails. > > > > Sound good? > Sounds good to me. > > > > -- ~devyn
On Tue, 2010-08-03 at 22:17 -0700, Devyn Cairns wrote: > > Why can't the stub .run just be a shell script (ie, portable) that > automatically checks the system type (uname) and consults the server > to find a build of Shoes that's compatible? > a '.run' file *is* a shell script with all directories in (say it's my shoes/dist) with it's platform specific .so, that are tar'd and binhexed or vice versa and appended to the end to the shell script which can be extracted/decoded with bash magic. But it you download my .run, you are going to get my AMD_X64 build and it's implicit links to shared libraries that depend on my ruby, and all the other my hidden dependencies. .Shy files aren't much different only they don't include the executables. We have to acknowledge that concept of Shoes distribution and script packaging with and without downloading a Shoes binary are three very different things to be kept in sync by the packager code and the website. Somehow. A skillful bash coder could probably figure out what version of Linux they are running under and download the proper (best) version of Shoes if it's available (it isn't at this point). On the third hand, that brilliant script could just download the source, compilers, and libraries and compile from source. A make script for the cloud?
On Tue, Aug 3, 2010 at 11:32 PM, Cecil Coupe <ccoupe@cableone.net> wrote: > On Tue, 2010-08-03 at 22:17 -0700, Devyn Cairns wrote: > > > > > Why can't the stub .run just be a shell script (ie, portable) that > > automatically checks the system type (uname) and consults the server > > to find a build of Shoes that's compatible? > > > > a '.run' file *is* a shell script with all directories in (say it's my > shoes/dist) with it's platform specific .so, that are tar'd and > binhexed or vice versa and appended to the end to the shell script which > can be extracted/decoded with bash magic. But it you download my .run, > you are going to get my AMD_X64 build and it's implicit links to shared > libraries that depend on my ruby, and all the other my hidden > dependencies. .Shy files aren't much different only they don't include > the executables. > Oh, no, perhaps you didn't get me clear—I already know that these are generated through *makeself*. But I think that the packaged scripts should, instead of downloading a generic .run, look for a better match on the site first. > > We have to acknowledge that concept of Shoes distribution and script > packaging with and without downloading a Shoes binary are three very > different things to be kept in sync by the packager code and the > website. Somehow. A skillful bash coder could probably figure out what > version of Linux they are running under and download the proper (best) > version of Shoes if it's available (it isn't at this point). > I was just saying that this exactly could be automatic. As far as I know, * uname* is specified by POSIX and therefore, the output should be predictable—so why not use it? > > On the third hand, that brilliant script could just download the source, > compilers, and libraries and compile from source. A make script for the > cloud? > > True. However, some distributions (for example, iirc, Ubuntu) don't include a compiler by default. Also, you would have to manage other distribution-specific dependencies (Shoes has a fair amount). If it were not for these points, I would agree. -- ~devyn
On Mon, 2010-08-02 at 12:52 -0700, Devyn Cairns wrote: > > > On Sun, Aug 1, 2010 at 11:16 PM, Cecil Coupe <ccoupe@cableone.net> > wrote: [snip] > > Don't get me wrong, I'm a cross-platform advocate too. I've run > Windows XP, then Ubuntu, then some other crazy distros until I met > Arch, and now I have a MacBook. It's important to me :] > > > But I think you could probably tone it down just a little? I'll try. Which dmg, 10.5 or 10.6 is going to be at the website when you pack a script for distribution?, As it's written now, there is one Windows and one OSX and one Linux for packaging. > --Cecil > > > > > -- > ~devyn