On 12 May 2011 19:09, Rafael Rivera wrote:
> Philip,
>
> Great feedback! Can you provide a copy of config.h? Would be helpful to see
> what gets created with mingw/msys and win32.
http://pastebin.com/k9qh7Vt8
This is from a working mingw build, not the failed MSVC stuff. Based
on the 1.4 source
Hullo all,
Buoyed by early success (read: dumb luck) at getting bzip to build, I
thought I'd have a go at gzip. Long story short, I haven't succeeded,
but it's raised some interesting questions. GNU gzip -
http://www.gnu.org/software/gzip/ - seems to be actively maintained,
unlike the stuff at g
IMHO the quality of parsing & validation is just as important as the
file format itself. I'd be happy to put up with most things in terms
of file format, on the proviso that if I get it wrong, autopackage
does a reasonable job of telling me what's wrong and where in the file
it is. FWIW I quite l
I know I've been inactive on this list (and on coapp in general) for a
while*, but let me be one of the first to say THANK YOU! One of the
reasons I didn't get very far when I was trying to contribute HTTP
fetcher code was simply because I couldn't figure out bzr. I wanted
to use it like it was g
I like servers. :) I don't know enough .NET to write one from scratch, but
could take a stab at modifying an existing one. I do have some stuff to sort
out before I can contribute any more code though (we have new contracts at
work, all a bit scary and legal and stuff), and am not too sure whether
ASP is a server-side language, yes. Not a language in which one would write
a server. To me, a server is a long-running process which deals directly
with network clients, not a bunch of code for dynamically generating content
on top of an existing web server.
Of course, I could be wrong about AS
You use the word server, but then mention ASP and Orchard (which I hadn't
heard of, but appears to be a CMS framework). I am confused. What nature
of beastie are we talking about here?
Regards,
Phil
___
Mailing list: https://launchpad.net/~coapp-develo
Optional dependencies can be a mixed bag, but aren't always simply a matter
of choice. Sometimes you might want to only build part of a large package,
which in its entirety provides more functionality than you need. Sometimes
dependencies might only be necessary to provide functionality lacking f
Hmm.. interesting concept, but it does raise a few questions for me. I'm no
expert, but know enough about supposed compiler-agnostic build systems to
know I wouldn't like to design one myself. ;)
Firstly, it strikes me that "what" and "how" are a bit mixed up in the XML
with the inclusion of even
Why would you want to? That might sound flippant, but it's a serious
question. If you're building a "proper" CoApp package, the
dependencies of which are also already CoApp packages, why would you
choose to forego automatically benefiting from (compatible) updates to
those dependencies?
There is
Is __int64 the most preferred type for large file support? Having had to
fix programs with large file issues in the past (and not always succeeding,
thanks to broken libraries), I've grown pedantic about the usage of correct
types. AFAIK, the preferred methodology for POSIX platforms is to use of
I did wonder about the layout after I first checked out. Reminded me
of when we tried to use git submodules at work - an experiment which
failed quite badly and put me off the idea until someone can convince
me otherwise. FWIW, we're trialling a different layout for another
multi-repository proje
On 22 June 2010 18:51, Garrett Serack wrote:
> !WAKE UP!
>
It's 8:30, I just got to work. :P
A little more seriously though, I for one have a half-decent dev environment
set up now, just the small matter of finding time...
___
Mailing list: https://la
I'm not Elizabeth, but since there was no reply (at least not that I can
see), I'll bite. Basically, there are only two (sensible) ways to do it:
callbacks, or a "get current status" function. The former is very common,
but does require a bit of thread safety awareness in the app's callback
imple
On 21 May 2010 17:57, Garrett Serack wrote:
> The plan of record is to have a small (<2k) bootstrapping DLL embedded in
> every MSI that acquires the CoApp core engine DLL--written in straight C, no
> additional off-platform dependencies that handles the entire dependency
> resolution & install
Think also of the amount of mirror infrastructure that already exists
in the form of big, dumb file servers. Regardless of whether or not
they're running Windows, they won't want to mirror CoApp packages if
that means setting up CoApp-specific web services.
___
On 21 May 2010 15:28, Adam Baxter wrote:
> I was hoping that the mirroring requirements would be platform agnostic. I
> mean come on, downloading, uncompressing and parsing an XML file is hardly a
> big deal, especially in managed code.
I agree with this. Mirroring requirements should be little
(stripped who wrote what, because with the last few posts to this
thread seemingly lacking any text not marked as reply, I've lost
track...)
>>> A compromise would be to have a very small bootstrapping CoApp engine
>>> with no dependencies, that downloads the necessary components, and
>>> eventual
I vaguely remember I too was calling for most of the "intelligence" to
be client-side, but at the time couldn't think straight enough to put
together a convincing argument as to why :) This is a good reason,
and something I for one am glad to see mentioned.
Regards,
Phil
On 20 May 2010 17:33, Ted Bullock wrote:
> On Thu, May 20, 2010 at 10:30 AM, Elizabeth Smith
> wrote:
>> Critical - repository for app-engine
>> Important - sample xml data
>> Wanted - sample msi package(s)
>
> +1
+2
___
Mailing list: https://launchpa
On 18 May 2010 11:07, Olaf van der Spek wrote:
> Obviously our API and ABI will be C. This doesn't mean the
> implementation has to be C as well, right?
It doesn't *have* to be, but it makes life much easier if it is. Any
other choice would see us fighting with the language to achieve our
goals
On 8 May 2010 06:37, William A. Rowe Jr. wrote:
> I look towards CoApp as a place offering builds of open source packages
> from open source, and mitigating the headaches for users. Which does
> point to one important point; when users leverage GPL code they will
> end up with a GPL application.
GTK+, GTK+, GTK+ and.. um.. GTK+.
OK, so I admit to having not thought very hard about this (did you
guess? ;) ), but it is currently *very* difficult to package apps
which use GTK+ well for Windows. In my experience, you either end up
hand-picking the parts of it you need and bundling them in yo
I know QA isn't quite the same thing as testing, but would there be
the resources floating around to have something like a continuous
integration server kicking around? It's a bit buzz-wordy, but knowing
a few minutes after you've pushed something* that you haven't broken
the build can be useful.
Hullo Garrett,
I have a few questions, the answers to which might be of use to others on
the list.
- Anything in particular we should do/read in preparation (other than the
obvious, like list posts/wiki)?
- Anything in particular we should bring so that we can be productive
while we're
On 15 April 2010 05:25, Gordon Schumacher wrote:
> Now let's pretend that a user has installed my WhizBangShellExt, but
> unbeknownst to me he's previously loaded CrustyExplorer, another shell
> extension. It also depends on libFoo.dll, but it's a much older
> application and is no longer support
On 14 April 2010 15:17, Garrett Serack wrote:
> WinSXS allows a publisher of a shared library to set the policy of the shared
> library so that if they put in a bug fix, but do alter the binary interface
> (ABI) then at run time, the application picks up the latest ("Most
> recommended") *binar
On 9 April 2010 17:36, Garrett Serack wrote:
> So part of CoApp is the evolution of some seriously cool magic that I've been
> working on for the last couple of years.
>
> Tools that can take absolutely any existing build process and turn it into
> Visual Studio project files. I've done this on
On 9 April 2010 17:28, Elizabeth M Smith
wrote:
> One thing that you're not addressing here is code. So you maintain a
> project, and you maintain it for windows. You do the work to make sure it
> compiles on windows and works on windows and doesn't need changes.
>
> Thank you! (A million times,
Hullo list, and in particular hello Mr. Serack!
This is a fantastic project idea, but I worry about the concept of
maintaining "shallow forks", and having to maintain two build
infrastructures for a project: one for UNIX (my personal choice being
autotools), and one for the CoApp build environment.
30 matches
Mail list logo
