newio-developers Mailing List for NewIO
Status: Alpha
Brought to you by:
cnystrom
Menu
▾
▴
newio-developers — NewIO Develoipers List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(37) |
Dec
(74) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(32) |
Feb
(45) |
Mar
(24) |
Apr
(38) |
May
(21) |
Jun
(1) |
Jul
(9) |
Aug
(9) |
Sep
(10) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2008 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(20) |
Dec
(2) |
| 2009 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(2) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jason R. <ja...@ne...> - 2011-02-04 03:13:54
|
Should be fine. Could also do after class. Up to you. On Thu, Feb 3, 2011 at 8:46 PM, Chris Nystrom <cny...@gm...> wrote: > On Thu, Feb 3, 2011 at 7:29 PM, Jason Reynolds <ja...@ne...> wrote: >> If you've got some time tonight, we can get it all working on orion. > > I am in class tonight. How does tomorrow night look? > > Chris > > -- > E-Mail: Chris Nystrom <cny...@gm...> > Saving the world from web programming. > http://www.newio.org - G-Talk: cnystrom > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > NewIO-developers mailing list > New...@li... > https://lists.sourceforge.net/lists/listinfo/newio-developers > |
|
From: Chris N. <cny...@gm...> - 2011-02-04 02:46:41
|
On Thu, Feb 3, 2011 at 7:29 PM, Jason Reynolds <ja...@ne...> wrote: > If you've got some time tonight, we can get it all working on orion. I am in class tonight. How does tomorrow night look? Chris -- E-Mail: Chris Nystrom <cny...@gm...> Saving the world from web programming. http://www.newio.org - G-Talk: cnystrom |
|
From: Jason R. <ja...@ne...> - 2011-02-04 02:26:08
|
If you've got some time tonight, we can get it all working on orion. On Thu, Feb 3, 2011 at 7:22 PM, Chris Nystrom <cny...@ne...> wrote: > On Mon, Jan 31, 2011 at 2:16 PM, Jason Reynolds <ja...@ne...> wrote: >> Awesome. Our guys will mirror it on www.emergingsoftware.net and >> we'll get to it :D > > Compile it and run it and let me know if it works for you, too. > > Chris > > -- > E-Mail: Chris Nystrom <cny...@ne...> > Saving the world from web programming. > http://www.newio.org/ - Freenode: #newio > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > NewIO-developers mailing list > New...@li... > https://lists.sourceforge.net/lists/listinfo/newio-developers > |
|
From: Chris N. <cny...@ne...> - 2011-02-04 01:22:24
|
On Mon, Jan 31, 2011 at 2:16 PM, Jason Reynolds <ja...@ne...> wrote: > Awesome. Our guys will mirror it on www.emergingsoftware.net and > we'll get to it :D Compile it and run it and let me know if it works for you, too. Chris -- E-Mail: Chris Nystrom <cny...@ne...> Saving the world from web programming. http://www.newio.org/ - Freenode: #newio |
|
From: Bob P. <bo...@pe...> - 2011-02-01 00:18:35
|
Yep, I'm still here! Bob Pendleton On Mon, Jan 31, 2011 at 12:29 AM, Chris Nystrom <cny...@ne...> wrote: > Is anyone still here? > > newio-110130 released > > A bug fix release. > > Tarball can be obtained here: > > http://www.newio.org/newio-110130.tar.gz > > Chris > > -- > E-Mail: Chris Nystrom <cny...@ne...> > Saving the world from web programming. > http://www.newio.org/ - Freenode: #newio > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > NewIO-developers mailing list > New...@li... > https://lists.sourceforge.net/lists/listinfo/newio-developers > -- +----------------------------------------------------------- + Bob Pendleton: writer and programmer + email: Bo...@Pe... + web: www.TheGrumpyProgrammer.com |
|
From: Jason R. <ja...@ne...> - 2011-01-31 20:24:37
|
Awesome. Our guys will mirror it on www.emergingsoftware.net and we'll get to it :D On Mon, Jan 31, 2011 at 12:29 AM, Chris Nystrom <cny...@ne...> wrote: > Is anyone still here? > > newio-110130 released > > A bug fix release. > > Tarball can be obtained here: > > http://www.newio.org/newio-110130.tar.gz > > Chris > > -- > E-Mail: Chris Nystrom <cny...@ne...> > Saving the world from web programming. > http://www.newio.org/ - Freenode: #newio > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > NewIO-developers mailing list > New...@li... > https://lists.sourceforge.net/lists/listinfo/newio-developers > |
|
From: Chris N. <cny...@ne...> - 2011-01-31 06:52:24
|
Is anyone still here? newio-110130 released A bug fix release. Tarball can be obtained here: http://www.newio.org/newio-110130.tar.gz Chris -- E-Mail: Chris Nystrom <cny...@ne...> Saving the world from web programming. http://www.newio.org/ - Freenode: #newio |
|
From: Jason R. <ja...@ne...> - 2009-03-01 12:25:09
|
That was such a quick hack I almost forgot do : objdump -d /path/to/binary > file2 then do: perl test.pl --bin=/path/to/binary Its still sorta busted. Quick ugly nasty hack. On Fri, Jan 30, 2009 at 3:41 PM, Jason Reynolds <ja...@ne...> wrote: > Hey, > > The idea has matured a little since my last e-mail. Basically what could > be done would be to make a > nio_bind_api([LIBNAME],[LIBVERSION],[OSTYPE],[IMPORT_NUMBER]) function that > would use a parser combined with a dynamic linker to integrate API libraries > which would more or less load the required .so, .dll, etc, and then you > could use nio_outside_call([API_IMPORT_NUMBER],[FUNCTION_SYMBOL],ARGS, ...) > or something along those lines to interface with a remotely loaded library. > In theory we could even get it to the point where once a library was loaded > we could actually just call its functions directly and overload them with > some super pointer fu on the back-end to make them run client side in stead > of server side. > The technique is similar in theory to writing shellcode for a buffer > overflow in a windows environment (pulling function pointers out of ntdll or > kernel32.dll, or even calling LoadLibraryA() or GetModuleHandleA() in > kernel32.dll and then enumerating through the new library altogether). I > have some decent stuff for PE parsing that I could implement in in-line > Assembly (Sorry about that) if anyone would not mind me giving that a shot > (since NewIO is in C) but I haven't managed to get my hands on a decent ELF > parser (any ideas anyone? please!?). Here's a little something on binary > formats: > > Usually there are certain offsets. Every so often there is a function > symbol, which is pointed to by the address immediately after the symbol > (ASCII is not going to execute as machine code). The symbol, for example's > sake, could be STRCPY in glibc6.1.so or STRCPY in ntdll.dll. Because it's > C the OS takes care of everything for us. Let's pretend it didn't. > > You determine the appropriate library to call from just from a local OS > detector inside of the client. > So you pull the pointer to STRCPY out of the required library, by parsing > it. Then you use the call (0xE9) > instruction, to execute it. > > You can see some examples of this in assembly in the "Second Staged > Shellcode" segment of > http://originallive.com/fdabuse which has win32 assembly for parsing > through ntdll and kernel32.dll > and linking dynamically then executing (we have to do dynamic linking with > shellcode because its > a flat binary. Almost think we should treat applications as flat binaries > on the client side as the > client is never actually given the direct logic code for it, it will behave > somewhat the same way). > > The same thing could be done with OpenGL, AGAR, Cairo, and other graphics > libraries or compiled > API libraries. > > I think something like this could also essentially move NewIO from it's > "alpha" stage to it's "beta" stage > because more applications and libraries would be supported virtually > overnight. Gonna see what I can > do in the way of an ELF parser. > > > On Thu, Jan 29, 2009 at 9:58 PM, Chris Nystrom <cny...@gm...> wrote: > >> On Wed, Jan 28, 2009 at 3:15 AM, Jason Reynolds <ja...@ne...> wrote: >> > Hey guys, >> > >> > Something I've realized about the current source tree is that it would >> be >> > easy (using the msg_send_[TYPE] functions and the header files to >> implement >> > functions) to write a parser to grab API's out of compiled binaries >> (ELF, >> > PE, etc) and parse them into usable NewIO C code to add functionality to >> the >> > client. You could really just prefix all the functions with >> _nio_[LIBNAME] >> > or something and add a switch to define I/O types (SDL, AGAR, OpenGL) >> > efficiently. >> > >> > Automated API imports can be difficult to actually release as a feature >> > though, and I haven't found a decent ELF parsing library (objdump's >> doesn't >> > actually look very nice). >> > Could definately make porting code a might bit simpler, though. >> Thoughts? >> >> That is an interesting idea. There must be a huge number of APIs out >> in the wild though right? >> >> Chris >> >> -- >> E-Mail: Chris Nystrom <cny...@gm...> >> Saving the world from web programming. >> http://www.newio.org - G-Talk: cnystrom >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> NewIO-developers mailing list >> New...@li... >> https://lists.sourceforge.net/lists/listinfo/newio-developers >> > > |
|
From: Jason R. <ja...@ne...> - 2009-03-01 12:12:44
|
Interesting news.
I have something that can identify api and sub-api level functions and we
can probably use as a linker with the right type of code. I can reformat
this output almost any way you like as well.
-------------CUT HERE--------------
#!/usr/bin/perl
# This code is really ugly. I sort of just hacked it together.
# Its a nice layout thing if you think about it. really gross
# hack though. I should learn more perlre.
use strict;
use Getopt::Long qw(GetOptions);
my $binary = '';
GetOptions('bin=s' => \$binary);
if (!$binary) {
print "specify --bin=/path/to/binary\n";
exit(1);
} else {
print "Re-mapping $binary...\n";
my $funcs = `objdump -d $binary|grep \\\>\\\:|sed s/\\\://g`;
print "Functions mapped..";
my $asm = `objdump -d $binary`;
print "..Disassembled!\n";
while ($funcs =~ /([0-9a-f]+).*\<(.*)\>/g) {
my $ptr = $1;
my $func = $2;
$ptr =~ s/08/8/;
print "$ptr points to $func\n";
while ($asm =~ /([0-9a-f]+):.*call.*$ptr/g) {
my $caller = $1;
my $infunc = `grep "\>\\:\\|$caller"
file2|grep -B1 $caller|head -1|awk '{print \$2}'`;
$infunc =~ s/:\n//g;
print "\t$caller in \`$infunc\'\n";
}
}
}
-------------CUT HERE--------------
So we may actually be able to do this whole api-wrapping thing after all.
This will work on ELF formatted
executables. I will explain here how to make it work with a .so file:
The output of the above application for a .so file will be flat because .so
files are flat binaries. What this
means is that the memory addresses start from 0x0.
Additionally, to make this work with an executable, newIO could
theoretically do this as well. Not sure
what reason you'd have except to port it to windows ;) hehehehe....
Anywho, since you're starting from 0x00000000, you'll have to find wherever
the .so is loaded in memory.
If it hasn't been loaded, we'll have to load it ourselves. Basically what
we'll need to do is add each "function
pointer" to the base pointer of the .so which is loaded into memory to find
the absolute pointer. At this point
we can just call it like:
int (*func)();
func = &ptr;
(int)(*func)();
Or something like that, I believe. The catch is you have to add it with hex
math, but there's all sorts of hex
to ascii apps for that. Thoughts? I know this is a crufty hack. I'm going
back and re-doing it already. Its
just somewhere to start.
On Thu, Jan 29, 2009 at 9:58 PM, Chris Nystrom <cny...@gm...> wrote:
> On Wed, Jan 28, 2009 at 3:15 AM, Jason Reynolds <ja...@ne...> wrote:
> > Hey guys,
> >
> > Something I've realized about the current source tree is that it would be
> > easy (using the msg_send_[TYPE] functions and the header files to
> implement
> > functions) to write a parser to grab API's out of compiled binaries (ELF,
> > PE, etc) and parse them into usable NewIO C code to add functionality to
> the
> > client. You could really just prefix all the functions with
> _nio_[LIBNAME]
> > or something and add a switch to define I/O types (SDL, AGAR, OpenGL)
> > efficiently.
> >
> > Automated API imports can be difficult to actually release as a feature
> > though, and I haven't found a decent ELF parsing library (objdump's
> doesn't
> > actually look very nice).
> > Could definately make porting code a might bit simpler, though.
> Thoughts?
>
> That is an interesting idea. There must be a huge number of APIs out
> in the wild though right?
>
> Chris
>
> --
> E-Mail: Chris Nystrom <cny...@gm...>
> Saving the world from web programming.
> http://www.newio.org - G-Talk: cnystrom
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> NewIO-developers mailing list
> New...@li...
> https://lists.sourceforge.net/lists/listinfo/newio-developers
>
|
|
From: Jason R. <ja...@ne...> - 2009-01-30 23:34:46
|
Hey, The idea has matured a little since my last e-mail. Basically what could be done would be to make a nio_bind_api([LIBNAME],[LIBVERSION],[OSTYPE],[IMPORT_NUMBER]) function that would use a parser combined with a dynamic linker to integrate API libraries which would more or less load the required .so, .dll, etc, and then you could use nio_outside_call([API_IMPORT_NUMBER],[FUNCTION_SYMBOL],ARGS, ...) or something along those lines to interface with a remotely loaded library. In theory we could even get it to the point where once a library was loaded we could actually just call its functions directly and overload them with some super pointer fu on the back-end to make them run client side in stead of server side. The technique is similar in theory to writing shellcode for a buffer overflow in a windows environment (pulling function pointers out of ntdll or kernel32.dll, or even calling LoadLibraryA() or GetModuleHandleA() in kernel32.dll and then enumerating through the new library altogether). I have some decent stuff for PE parsing that I could implement in in-line Assembly (Sorry about that) if anyone would not mind me giving that a shot (since NewIO is in C) but I haven't managed to get my hands on a decent ELF parser (any ideas anyone? please!?). Here's a little something on binary formats: Usually there are certain offsets. Every so often there is a function symbol, which is pointed to by the address immediately after the symbol (ASCII is not going to execute as machine code). The symbol, for example's sake, could be STRCPY in glibc6.1.so or STRCPY in ntdll.dll. Because it's C the OS takes care of everything for us. Let's pretend it didn't. You determine the appropriate library to call from just from a local OS detector inside of the client. So you pull the pointer to STRCPY out of the required library, by parsing it. Then you use the call (0xE9) instruction, to execute it. You can see some examples of this in assembly in the "Second Staged Shellcode" segment of http://originallive.com/fdabuse which has win32 assembly for parsing through ntdll and kernel32.dll and linking dynamically then executing (we have to do dynamic linking with shellcode because its a flat binary. Almost think we should treat applications as flat binaries on the client side as the client is never actually given the direct logic code for it, it will behave somewhat the same way). The same thing could be done with OpenGL, AGAR, Cairo, and other graphics libraries or compiled API libraries. I think something like this could also essentially move NewIO from it's "alpha" stage to it's "beta" stage because more applications and libraries would be supported virtually overnight. Gonna see what I can do in the way of an ELF parser. On Thu, Jan 29, 2009 at 9:58 PM, Chris Nystrom <cny...@gm...> wrote: > On Wed, Jan 28, 2009 at 3:15 AM, Jason Reynolds <ja...@ne...> wrote: > > Hey guys, > > > > Something I've realized about the current source tree is that it would be > > easy (using the msg_send_[TYPE] functions and the header files to > implement > > functions) to write a parser to grab API's out of compiled binaries (ELF, > > PE, etc) and parse them into usable NewIO C code to add functionality to > the > > client. You could really just prefix all the functions with > _nio_[LIBNAME] > > or something and add a switch to define I/O types (SDL, AGAR, OpenGL) > > efficiently. > > > > Automated API imports can be difficult to actually release as a feature > > though, and I haven't found a decent ELF parsing library (objdump's > doesn't > > actually look very nice). > > Could definately make porting code a might bit simpler, though. > Thoughts? > > That is an interesting idea. There must be a huge number of APIs out > in the wild though right? > > Chris > > -- > E-Mail: Chris Nystrom <cny...@gm...> > Saving the world from web programming. > http://www.newio.org - G-Talk: cnystrom > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > NewIO-developers mailing list > New...@li... > https://lists.sourceforge.net/lists/listinfo/newio-developers > |
|
From: Chris N. <cny...@gm...> - 2009-01-30 03:58:34
|
On Wed, Jan 28, 2009 at 3:15 AM, Jason Reynolds <ja...@ne...> wrote: > Hey guys, > > Something I've realized about the current source tree is that it would be > easy (using the msg_send_[TYPE] functions and the header files to implement > functions) to write a parser to grab API's out of compiled binaries (ELF, > PE, etc) and parse them into usable NewIO C code to add functionality to the > client. You could really just prefix all the functions with _nio_[LIBNAME] > or something and add a switch to define I/O types (SDL, AGAR, OpenGL) > efficiently. > > Automated API imports can be difficult to actually release as a feature > though, and I haven't found a decent ELF parsing library (objdump's doesn't > actually look very nice). > Could definately make porting code a might bit simpler, though. Thoughts? That is an interesting idea. There must be a huge number of APIs out in the wild though right? Chris -- E-Mail: Chris Nystrom <cny...@gm...> Saving the world from web programming. http://www.newio.org - G-Talk: cnystrom |
|
From: Jason R. <ja...@ne...> - 2009-01-28 10:23:31
|
Hey guys, Something I've realized about the current source tree is that it would be easy (using the msg_send_[TYPE] functions and the header files to implement functions) to write a parser to grab API's out of compiled binaries (ELF, PE, etc) and parse them into usable NewIO C code to add functionality to the client. You could really just prefix all the functions with _nio_[LIBNAME] or something and add a switch to define I/O types (SDL, AGAR, OpenGL) efficiently. Automated API imports can be difficult to actually release as a feature though, and I haven't found a decent ELF parsing library (objdump's doesn't actually look very nice). Could definately make porting code a might bit simpler, though. Thoughts? |
|
From: Chris N. <cny...@ne...> - 2009-01-23 01:03:16
|
In the future "the network will be the computer". This old marketing phrase from Sun Microsystems will be fulfilled. Right now people still think of computers as individual entities, but that is changing. We build supercomputers not with big iron, but with collections of smaller computers. For example, the fastest computer in the world as I write this, the IBM Roadrunner consists of a cluster of 3240 computers. Another example is grid computing where you can add or subtract computers to depending on the needs of the users. From Grid computing we get cloud computing where real-time scalable resources are provided as a service over the Internet. These services are typically provided from a collection of, you guessed it, PCs in a data center somewhere. The current situation is that there is not one cloud right now, but a number of individual clouds each provided by a vendor. Now here is the deal. When these clouds seamlessly inter-operate, then we will have one global computer and one global operating system. For this reason, I think this might be very important going forward: http://groups.google.com/group/cloudforum Unfortunately, it looks to me like they still want to base this on an HTTP like protocol. http://wiki.gogrid.com/wiki/index.php/API_Getting_Started_Guide I would love to see the internet as a massively distributed operating system something like Plan 9 but on a much larger scale, with public APIs for storage servers, authentication servers, and I/O or application servers. And, of course, the application I/O should be something more suitable for the purpose like NewIO (or better) instead of HTTP. Chris -- E-Mail: Chris Nystrom <cny...@ne...> Saving the world from web programming. http://www.newio.org/ - Freenode: #newio |
|
From: Chris N. <cny...@ne...> - 2009-01-22 23:09:11
|
newio-090122 released A bug fix release. The new release includes update to use the latest version of the ffmpeg library for video (I hate it when they change the location of header files). It also includes fixes to the text box for the URL input. There are no compatibility changes. Tarball can be obtained here: ftp://ftp.newio.org/pub/newio/newio-090122.tar.gz Chris -- E-Mail: Chris Nystrom <cny...@ne...> Saving the world from web programming. http://www.newio.org/ - Freenode: #newio |
|
From: Chris N. <cny...@gm...> - 2008-12-09 12:55:30
|
On Tue, Dec 9, 2008 at 2:44 AM, Olli Aalto <oa...@gm...> wrote: > http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html > > Chris, you might want to pipe in to the conversation on this one? Thank you. I will. No time at the moment. I am getting ready to pitch NewIO to a client down in San Antonio and am just about ready to leave. Anyway their mistake was right at the start: "At Google we're always trying to make the web a better platform." They are trying to dress up a pig. I would like to see what they could do if they scrapped the web as a platform and created a new Internet platform from scratch. It would be much different than the web. Chris -- E-Mail: Chris Nystrom <cny...@gm...> Saving the world from web programming. http://www.newio.org - G-Talk: cnystrom |
|
From: Olli A. <oa...@gm...> - 2008-12-09 08:44:14
|
http://google-code-updates.blogspot.com/2008/12/native-client-technology-for-running.html Chris, you might want to pipe in to the conversation on this one? O. |
|
From: Chris N. <cny...@ne...> - 2008-11-29 20:46:08
|
http://developers.slashdot.org/article.pl?sid=08/11/28/1335248 Read the comments. The web as an application platform continues to be hated. Also, I made this diagram in a presentation recently: (Apps) (Apps) (MS_DOS) -----> (Linux, etc) (PC Hardware) (PC Hardware) (Apps) (Apps) (Web) -----> (NewIO) (OS) (OS) (PC Hardware) (PC Hardare) For a number of years MS-DOS owned the PC world and was ubiquitous. Eventually people got tired of the shortcomings and moved on to something better. Except the comparison to the web is even worse than implied here, because at least MS-DOS was designed to run apps and, of course, the web never was. Chris -- E-Mail: Chris Nystrom <cny...@ne...> Saving the world from web programming. http://www.newio.org/ - Freenode: #newio |
|
From: Chris N. <cny...@ne...> - 2008-11-27 21:13:04
|
New Win32 binary release: ftp://ftp.newio.org/pub/d0/DreadnoughtBrowserSetup-081121.exe Had to rebuild my Win32 development environment. Chris -- E-Mail: Chris Nystrom <cny...@ne...> Saving the world from web programming. http://www.newio.org/ - Freenode: #newio |
|
From: Jason R. <ja...@ne...> - 2008-11-27 08:57:20
|
I would have to concur. I can put forth a bit of effort in terms of linking certain functional primitives to higher-level in addition. Things like color blending, certain animation affects - all of those are sort of OpenGL native except for they take say five function calls (which 3 or 4 usually just take standard defaults) -- I think a few of them could be made into a single function. I'm willing to give that bit a whirl. On Mon, Nov 3, 2008 at 8:58 PM, Chris Nystrom <cny...@gm...> wrote: > On Mon, Nov 3, 2008 at 8:09 PM, Alan Kleymeyer wrote: > > > > I am currently working on an OpenGL portability layer to create a desktop > > application UI for Windows and Mac. I can put some effort to help any > > project using OpenGL in NewIO. > > That would be great Alan. > > I am thinking the best way would be to use SDL in combination with > OpenGL as SDL does some things that OpenGL does not, but we would use > OpenGL for rendering. Something like these: > > http://www.libsdl.org/opengl/index.php > > I am thinking the best thing to do API wise it just copy the OpenGL > API as much as possible. > > I think I can get a first pass on linux. Then you can verify that it > still works under Windows and OSX and then from there we can all work > on extending it. > > Thoughts? > > Chris > > -- > E-Mail: Chris Nystrom <cny...@gm...> > Saving the world from web programming. > http://www.newio.org - G-Talk: cnystrom > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > NewIO-developers mailing list > New...@li... > https://lists.sourceforge.net/lists/listinfo/newio-developers > |
|
From: Chris N. <cny...@gm...> - 2008-11-22 03:08:55
|
New release: ftp://ftp.newio.org//pub/newio/newio-081121.tar.gz Minor bug fixes. Still compatible with previous versions. Getting back into the swing of things. Chris -- E-Mail: Chris Nystrom <cny...@gm...> Saving the world from web programming. http://www.newio.org - G-Talk: cnystrom |
|
From: Chris N. <cny...@ne...> - 2008-11-18 21:59:50
|
Attached and included is an open source project checklist created from ideas in Producing Open Source Software by Karl Fogel. At first I thought I would go through this myself, but now I think it might be better if someone less familiar with the project wanted to take a crack at it. I am thinking that someone less familiar with the project might be more objective about the strengths and weaknesses of where we are at than I am. Do we have a volunteer? Thank you in advance, Chris -- Open Source Project Checklist by Chris Nystrom Concepts from: Producing Open Source Software by Karl Fogel (http://producingoss.com/en/producingoss.html) 1. Does the project scratch someone's itch? 2. Does the web site appeal to developers? 3. Does the web site appeal to users? 4. Is there an existing project that does what you want? 5. Is the goal of the project expressed clearly? 6. Did you choose a good name? 7. Does the project name suggest what the project does? 8. Is the project name easy to remember? 9. Is the project name the same as any other project's name? 10. Is the project name trademarked? 11. Is the project's name domain available, especially in the .ORG domain? 12. Does the project have a clear mission statement? 13. Is the mission statement concrete? 14. Is the mission statement limited? 15. Is the mission statement short? 13. Is the mission statement on the front page of the web site? 14. Is it unambiguously clear on the home page that the project is open source? 15. Does the home page list the features? 16. Does the home page list the requirements? 17. Does the home page list the development status? 18. Is the software downloadable as source code in standard formats? 19. Does the software conform to standard build methods? 20. Does the software conform to standard installation methods? 21. Does each release have a unique version number? 22. Does the project use version control? 23. Does the project use a bug tracker? 24. Does the project have a feature request tracker? 25. Does the project have a mailing list(s)? 26. Does the web site include how to join the mailing list(s)? 27. Does the project have an IRC channel? 28. Does the web site include information about the IRC channel? 29. Does the project have developer guidelines? 30. Do the developer guidelines include pointers to forums for interaction with other developers? 31. Do the developer guidelines include instructions on how to report bugs and submit patches? 32. Do the developer guidelines include some indication of how development is usually done (is the project a benevolent dictatorship, a democracy, or something else)? 33. Does the project have documentation? 34. Does the documentation include how to quickly set up the software? 35. Does the documentation include an overview of how it works? 36. Does the documentation include some guides to doing common tasks? 37. Does the documentation include how much technical expertise the users expected to have? 38. Does the documentation list areas that are known to be incomplete? 39. Is the documentation available online? 40. Is the online documentation browseable? 41. Can you click on one link to bring up the entire documentation? 42. Is the documentation included with the software download? 43. Does the project have a Frequently Answered Questions (FAQ)? 44. Does the project have developer documentation? 45. Does the project have a wiki? 46. Are there screenshots on the web site? 47. What license does the project use? 48. Is the license listed on the home page with a link to the text? 49. Are project discussions private or public? 50. Is rudeness in project communications nipped in the bud? 51. Does the project have code reviews? 52. Are commit e-mails turned on? 53. Are you open sourcing an existing project? 54. If so, have you sent out a warning in advance? 55. Are new code releases announced on freshmeat.net? 56. Are new code releases announced on any mailing lists? 57. Are new code releases announced on any news groups? -- E-Mail: Chris Nystrom <cny...@ne...> Saving the world from web programming. http://www.newio.org/ - Freenode: #newio |
|
From: Chris N. <cny...@gm...> - 2008-11-18 17:30:51
|
On Tue, Nov 18, 2008 at 9:15 AM, Jason Reynolds <ja...@ne...> wrote: > > As far as OpenGL/GLUT goes, there are basic primitives similar to SDL > primitives. There are also some basic animations that are similar. I think > that porting those is a good idea; I also don't want to see all that AGAR UI > code go to waste. I can hit some design stuff on the site soon too, and if > you like I can kickstart the ircd (I'll need sudoers and a new shell; 52 > char passwords for the lose if you don't type them in for two weeks). Access is no problem, but do you think we really need our own IRC server? Seems like freenode is good enough for now. What do you think? > AGAR might be a good way to go because it was an API built on top of > OpenGL/SDL. It's all Obj-C using callbacks to handle the event procedures, > at least that's my understanding of what was originally going on with that > AGAR-NEWIO code base. It does also have easy compatibility with the > nintendo wii/gamecube. Personally, I know the GLUT subroutines much moreso > than I know the AGAR subroutines. Would take more research to truly work > on. It seems like no matter what we are going to need OpenGL, so I am working on that. Chris -- E-Mail: Chris Nystrom <cny...@gm...> Saving the world from web programming. http://www.newio.org - G-Talk: cnystrom |
|
From: Jason R. <ja...@ne...> - 2008-11-07 22:07:57
|
Ill write some docs Guve me a few weeks Busy with personal stuff lately On 11/3/08, Olli Aalto <oa...@gm...> wrote: > On Sun, Nov 2, 2008 at 4:55 PM, Chris Nystrom <cny...@gm...> wrote: >> I think the big advantage of using NewIO with games is that you would >> only have to write the game once, and then it would be compatible on >> all of the major platforms (linux, OSX, and windows). >> > > Yes, plus updating the game would be a simple matter. > >> There also might be some advantages in a client/server type setup >> since NewIO basically handles all of the client/server part for you. >> > > It would be perfect for network-aware games and features, everything > from scoreboards to fullblown deathmatch games. > >>> Something like that might interest me. Would make a nice little >>> problem to tackle. >> >> I have not done a lot of OpenGL programming but it looks like it might >> be as simple copy the OpenGL api, and then just send the calls over >> the net to the NewIO client. That is more or less how it is currently >> done, except that SDL is used instead of OpenGL. >> > > I'll need lots of information for this. For example: > How does the client know which function to call? How does the protocol work? > > So before starting to do anything about it, more work should be done > on the documentation front. > >>> But first I'd like to see a definite plan for the >>> future. How the project can be made to interest other people. Polish >>> the website and documentation as well as the code. And I'm willing to >>> help on that too. Fo example I could write about what I feel a areas >>> that need attention and fixing. >> >> That would be great. I agree that pretty much everything needs some >> polish. I would be interested to hear what you think needs to be done, >> and what the priorities are for those tasks. >> > > Documentation is king. No question about it. Examples are good to have > too, but you can have fewer of them because you can cover more stuff > in just one example. > > Also I would split the nio_lib.h header into smaller pieces, for example. > >>> Actually I could start now with one >>> thing; the irc server wasn't responding. :) You could think switching >>> to freenode.org, if hosting the irc server is something that you don't >>> have time and/or interest. E-mail is all well and good but it's easier >>> to converse in irc. >> >> Jason set that up. I went on the server, but I was unable to locate >> the startup script. It is apparently not in /etc/init.d. I could >> probably install a new server if that is a priority, or we could go >> with freenode.org. >> >> Probably just instant messaging with gtalk will work for now, but >> having an IRC channel might help with the publicity angle. Now that I >> think about it, maybe freenode.org is the way to go as that might be >> the best way from a publicity angle. >> > > A lot of projects use freenode, so that's a quite a safe bet. > >>> Let me know what you think. >> >> Good idea. I think the first thing I am going to do is use the above >> book to come up with a todo list. >> > > That's a good start. Let me know when you have a list, I'll give more > feedback then. Also we can check if there is something I can do also. > > O. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > NewIO-developers mailing list > New...@li... > https://lists.sourceforge.net/lists/listinfo/newio-developers > |
|
From: Chris N. <cny...@gm...> - 2008-11-07 22:01:06
|
On Fri, Nov 7, 2008 at 3:49 PM, Olli Aalto <oa...@gm...> wrote: > > If you want an alternative to SDL take a look at > GLFW(http://glfw.sourceforge.net/). No, it looks like SDL/OpenGL is the way to go. Thanks, Chris -- E-Mail: Chris Nystrom <cny...@gm...> Saving the world from web programming. http://www.newio.org - G-Talk: cnystrom |
|
From: Olli A. <oa...@gm...> - 2008-11-07 21:49:28
|
On Fri, Nov 7, 2008 at 11:14 PM, Chris Nystrom <cny...@gm...> wrote: > Is it a good idea to use the OpenGL Utility Toolkit (GLut) ? > No. The old glut is really old. There is at least one open source version hanging around(freeglut) but I think that's dead too. Haven't been updated in many years. If you want an alternative to SDL take a look at GLFW(http://glfw.sourceforge.net/). O. |
1 message has been excluded from this view by a project administrator.