Hey Everybody!
I'm rather impressed that there's a website up
and a mailing list and everything. I am not
yet back among the living (I'm stranded in Limbo)
and visiting friends in NYC (going to linux world
too). But this very cool!
I'm glad to hear there is some
progress being made. When I r
--- Patrick A <[EMAIL PROTECTED]> wrote:
> Just two cents, but David mentioned uploading
> sdlperl2.0 once he was back in
> civilization.
By all means do not let my 2.0 statement stop
the Config work, I have absolutely no problem
with that, and the 2.0 stuff (while there are
some config improvem
Ok,
Now I'm going through the build system
changes and I can't build a damn thing
on a fresh fedora install because the
new build stuff requires a metric boatload
of cpan.
my dev box, for reasons too complex to
get into has no net connection, and
solving these dependencies by hand has
already ta
First off thanks to all those that have
contributed, this is getting really impressive.
In the next couple of hours 2.0.5 will be
floating around the cpan mirrors, it has
the Tels inspired scalar refs implemented
throughout, chromatic's new build system
and tutorials, and a number of functions
tha
http://backpan.cpan.org/authors/id/D/DG/DGOEHRIG/
2.0.5 is there, have not been able to post
the patches, keep being rejected because of
mydoom filters.
Also, I'm having a terrible time getting
the damn thing indexed, because wayne has
permissions on half the modles. Wayne are you here?
If some
attaced is a tarball containing most of the patches
needed to get fb fully working with 2.0.5
I have also begun serious work for the next
minor release that adds improved SMPEG
support, tighter integration with SDL_mixer,
and if I get the time, a sprite library or two.
I'm working on a general i
doh!
--- John Beppu <[EMAIL PROTECTED]> wrote:
> [ date ] 2004/02/09 | Monday | 09:18 AM
> [ author ] david goehrig <[EMAIL PROTECTED]>
>
> > attaced is a tarball containing most of the
> patches
> > needed to get fb fully working with 2.0.5
>
In the 2.0.5 branch there is a method
SDL::Surface::rect ([x,y])
which retuns a SDL::Rect with the given x,y
(0,0) if not specified.
usage
my $app = new SDL::App;
my $image = new SDL::Surface -name => 'player.png';
$image->blit(0,$app,$image->rect(10,20));
Usually I subclass Surface into Spr
> What is not the official SDL perl
> release/repository?
CPAN is going to be the release repository.
Andreas finally fixed the permissions and I
can finally submit distributions again.
> Is David just using sdl.perl.org?
I am in full support of using sdl.perl.org
and I'd recommend we get a wik
--- "Scott R. Godin" <[EMAIL PROTECTED]> wrote:
>
> Also CPAN thinks it's version 2.0 not 2.0.5
yeah CPAN has a lot of screwy ideas. There
were problems with the distribution import
and so the metadata got kinda screwy
As for the install failure, it looks like it is that
the test is failing
--- John Beppu <[EMAIL PROTECTED]> wrote:
> However, you don't have to chronicle your every
> little move. For example, if you need to reformat
> a few lines of code here and there
> or add a few comments, just do it.
>
> Use your judgement to determine what's noteworthy
> and what's not.
I just
I just figured out what changed and broke the OpenGL
stuff, it was a bootsrap code change.
Previous versions automatically loaded the OpenGL.so
if you had it, regardless of if you need it.
In fixing that the export of the functions into the
main namespace by including SDL::OpenGL failed,
because i
Any and all,
I'm going over the diff between the 2.1.0 branch and the version in
svn.perl.org,
and there are currently 8759 lines different, many of which are due to the new
style pointer wrapping over the old 1.2.x hash wrapping. As such I'm going
through the svn change log, looking for things t
Hey all,
I've uploaded the lastest buildable revision 2.1.1 to
http://sourceforge.net/projects/sdlpl/
You can download the tarball there. I haven't yet
integrated the build changes to this version, this has
only the feature improvement / bug fixes patched.
Build system bug fixes comming RSN.
I'm not wrapping anything up for any particular platform any time
soon. What is in
SVN is the latest and greatest, and may be what is in CPAN I don't remember.
If someone wants to package it for various platforms, be my guest. But since
most people package the earlier branch that works with Froze
k for write access to the respository.
The code is accessible through the web.
Dave
On Wed, 24 Nov 2004 16:09:21 -0600, Andy Bakun
<[EMAIL PROTECTED]> wrote:
> On Wed, 2004-11-24 at 14:01, David Goehrig wrote:
> > I'm not wrapping anything up for any particular platform any t
Guillaume,
You should not apologize, as you're responsible for acceptance in the
first place.
Great to hear you've got the networking going.
Thanks for a great game,
Dave
On 25 Nov 2004 11:43:15 +0100, Guillaume Cottenceau <[EMAIL PROTECTED]> wrote:
> David Goehrig writes
type
sdl-config --libs
you should get back a listing like:
-L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread
What the error message says is quite clear, it can't find SDL and it is first
checking /usr/local/lib, and then looking in /usr/lib. If you have installed
SDL in /usr/local/lib, you may ha
I just uploaded a minor patch release that corrects some bugs with the
build process.
SDL_perl-2.1.3 should be hitting the CPAN mirrors soon.
Dave
--
"The universal aptitude for ineptitude makes any human accomplishment an incredible
miracle"
-Stapp's Ironical Paradox
On 10/11/05, Andreas Lund <[EMAIL PROTECTED]> wrote:
>
>
> Hello again :-)
Hi
But when I try to fetch this info with glGet, it appears there is no such
> subroutine... is there some fancy trick I have overlooked, or is this a
> known problem with sdlperl?
>
>
In sdl-perl-2.1.3 (and some earlier
Well I've spent too many of the past 48 trying to get SDL Perl up an running
on my PowerBook. I will totally admit SDL Perl was truly broken on the Mac
platform. What this effort has resulted in though, is something rather
different. I'm a few hours away from putting together an SDL Perl.app bundle
Well there is already an OpenGL and GLUT module in CPAN that is
entirely independent of the on in SDL_Perl. The reason I did this
version was because the other is a more or less strict interpretation
of the C API, and I wanted something simpler that more cleanly
integrated with perl's programming
RT bugs go to me anyways :)
I am swampped with work.
Please be patient, I'll get to it eventually.
Dave
On 3/1/06, Tels <[EMAIL PROTECTED]> wrote:
> Moin,
>
> On Tuesday 21 February 2006 19:19, chromatic wrote:
> > On Monday 20 February 2006 11:27, Chris Hinrichs wrote:
> > (That reminds me, we
Ok, I took a few minutes out to change the configuration of my
webserver and added a new repository, uploaded my current working
code, and set the SVN repository up.
http://nexttolast.com/sdlperl
Anyone can make changes, but when you do please send me an email
telling me what you did. If I do a
Tels when you checkout of the repository you create your own Local branch.
When you've finished testing and verified that your code is right,
check it in to the main tree.
When a release is made, for sanity sake, I will import the release as
another branch. All development should happen in the ma
The Credits can be extracted from the Changelog file.
The copyright notices were standardized upon the request of the people
who run savanna.gnu.org which I was at one point applying for a
repository. They were changed to meet the requirements of both the
LGPL and legal requirements.
Please do
The version number scheme is simple and will remain the same.
major.minor.patch
Major releases changes break everything... 1 -> 2 changed how
everything worked internally and that broke a lot of code that poked
around inside the internals of things.
Minor releases happen when API changes are mad
About merging branches. I want to point out that most of the branches
are incompatible with the current version of SDL perl internally. The
SDL_perl-2.2.0 release which is in SVN right now is based on the major
rewrite were we moved to blessed scalars for the entire OO layer, and
made lots of int
On 3/6/06, Pip Stuart <[EMAIL PROTECTED]> wrote:
> use even minor versions to suggest stability and odd
> to imply unstable / experimental development branches.
All releases are supposed to be "stable" until proven otherwise :)
SVN is "unstable" and CPAN is "stable". You want to be bleeding edge
Hey all,
I'm around but busy as usual. Subversion is still up at
http://nexttolast.com/sdlperl
And always collecting submissions.
Sorry I haven't been pushing out much code, but life keeps getting in
the way :)
Dave
Everybody,
I just went through the build process on Mac OS X and Debian, and fixed
up a few bugs that were created as a result of a change in Module::Build
that I've been too lazy to correct, and a few other bugs that cropped up
as part of getting the SDLPerl.app bundle working under MacOS X.
not the test is broken, and not the underlying code), I'm in no rush to
fix them. Volunteers are more than welcome to take on that task.
Thanks for the report
Dave
John Gabriele wrote:
On 3/11/07, David Goehrig <[EMAIL PROTECTED]> wrote:
Everybody,
I just went through the buil
Rich
Could you send me a list of your OS, the full error message text, and
the locations you've installed all the libs `locate SDL`?
It looks like it is failing to initialize the list of directories for
the various libraries on your system.
Dave
Turd Turtle wrote:
Hi there,
I am havin
I'll pull review and merge.
Dave
-=-=- d...@nexttolast.com -=-=-
On Aug 2, 2009, at 11:39 AM, Kartik Thakore
wrote:
Now SDL_perl has support for
OpenGL gluquadric* stuff.
an example is made available from NeHe lesson 18. (GL_SMOOTH doesn't
seem to work)
The file is in test/OpenGL/tutoria
Since Kartik Thakore has expressed interest in getting SDL Perl back
in gear, I'm going to help the SDL Perl community get back into the
swing of things.
At the request of Carlo "zED" Caputo and Rodolfo Borges, I moved the
development repository off of a now defunct SVN server, into github.
The new
kartik,
I have a Windows instance that I use for testing builds, but it is dumped on
a backup tape somewhere. Let's try to unravel what we really need to
produce a more friendly build system. Also in the 2.2.x branch, there is
the preliminary work for a MacOS X applet dropper, and I'd like to bui
Since Kartik Thakore has expressed interest in getting SDL Perl back
in gear, I'm going to help the SDL Perl community get back into the
swing of things.
At the request of Carlo "zED" Caputo and Rodolfo Borges, I moved the
development repository off of a now defunct SVN server, into github.
The new
Just a historical FYI. I did a version of the thunk based calls for
Sdl Perl in around 2k2 and it works ok. The real issue is not the
several C ABI variants that need to be supported (6 main ones with
slight variants) the problem is Making some of the calls "perlly".
So if we are ambitious
As soon as we have a decent build system back in place for win32/64,
let's assume 2.3 will move on to a new build scheme. So basically we
fix this and I'll push to cpan and we move on.
Curtis if you have a few minutes could you send me a quick description
of your setup. My windows box is cu
The "black magic" is perl5 typeglob programming 101. GV in the perl
internals pods. As for the behavior change there was a reason. But I
don't remember what it was. :)
I will take a look when my kid is asleep.
Dave
-=-=- d...@nexttolast.com -=-=-
On Aug 17, 2009, at 1:04 PM, Kartik Thakore
The answer is use DESTROY. And there was at one point a SDL::free
method, but who knows if is still around.
Best advice on mem leaks is stop doing that. And by that I mean what
your doing. You should never assume that it is safe to free anything
when dealing with complex systems.
Typicall
Ages ago all of the xs code was broken out into separated files. We
switched over to a monolithic build with conditional compilation due
to the problems of maintaining coherency in the face of nested
dependencies.
One of the things the old build scripts did that the new pseudo-cpan-
friend
On Mon, Aug 31, 2009 at 11:54 AM, Kartik
Thakore wrote:
> What if this was fixed with Alien::SDL as it is doing for windows now? Kmx
> is also working on strawberry compatible makefiles. This way we can compile
> for most platforms from scratch.
The problem is as Andreas originally pointed out th
On Mon, Aug 31, 2009 at 1:06 PM, Kartik Thakore wrote:
>
> But it does solve dev env setup for the developer.
Not really, it partially solves the configuration/detection problem
but still fails the "what the dev really needs" test. If I'm writing
software that I want to distribute, then I need a
mmon across all large
middleware platforms.
The model to think of is games that require the latest directx and
require you install that.
Dave
-=-=- d...@nexttolast.com -=-=-
On Aug 31, 2009, at 9:39 PM, Adam Kennedy
wrote:
2009/9/1 David Goehrig :
What if this was fixed with Alien::SDL
-=-=- d...@nexttolast.com -=-=-
On Sep 1, 2009, at 8:56 AM, Guillaume Cottenceau
wrote:
or urpmi :)
I know, I know, mandriva is just not hype anymore..
Was it ever :)
Thanks. Well, I can't remember how I first tried sdl-perl. I surely
don't like/use cpan a lot, so I am not sure if i
-=-=- d...@nexttolast.com -=-=-
On Sep 1, 2009, at 9:25 AM, Kartik Thakore
wrote:
If you remember or can find them some of the bugs. Can you post them
onto RT?
If Guillaume can remember a single bug from those days without looking
it up I'll buy him a beer next time I'm on the Contin
On Tue, Sep 1, 2009 at 8:40 PM, Adam Kennedy wrote:
> This is where I see the SDL CPAN package. You develop initially on the
> CPAN version, then do packaging and testing targeting the
> installed/packaged/bundled/all-in-one version.
I think this is where we're getting messed up I don't thin
48 matches
Mail list logo
