Re: [Coapp-developers] Another kind of package.
ntain files (PHP, ASPX, etc) that have a high likeliness of needing modifications—which is heavily discouraged in [\Program Files]. The typical installation if they are using IIS would be [\inetpub\wwwroot\] but that makes a strong assumption that they want it in the default web root. We could make some assumptions and go with [\inetpub\applications\\] regardless of webserver--Apache or IIS could be easily configured to pick up the app from there (regardless of virtual root or virtual app directory). Ideas? Feedback? And, is there a more generic case that this is part of—packages that are not really executables, but large collections of files that are used to drive a particular purpose (and aren’t ‘documents’ either)? Garrett Serack | Microsoft's Open Source Software Developer | Microsoft Corporation Office:(425)706-7939 email/messenger: garre...@microsoft.com blog: http://fearthecowboy.com twitter: @fearthecowboy I don't make the software you use; I make the software you use better on Windows. ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp -- Trevor Dennis -- Trevor Dennis ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp Ack - top-posting ;) Yes, I really think that web applications need their own package, putting them in program files is not only a pain because they might need to write to configuration files/generate images/do other bad stuff but it's also a security issue. For example apache makes you set up specific locations that are allowed to run scripts. I do NOT want that to be in program files but somewhere else I can keep a tighter lock and key on. In the PHP world GOOD application typically do NOT put their scripts in the web root, but parallel to it (take a look at the general structure that zend framework uses) - basically it sets up their own sub tree of /application /config /lib /htdocs/www/whatever we call it this week (the actual web root) some kind of setup that uses $base_web_location/// would work fine, with each package having it's own webroot and virtual host As to the last issue - the idea of "useful scripts" - maybe there needs to be a place for general command line scripting stuff, as opposed to lumping all 'desktop applications' together. To further complicate things there is the idea of things in the PHP that script libraries like PEAR and Zend Framework are installed to program files somewhere - and then web applications that are installed put them into their include_paths. In essence you're installing a "library" - but it's going to have much different usage needs and patterns then a traditional library/.dll Ugh - too many ways to do things. Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Another kind of package.
On 4/6/2010 2:23 PM, Garrett Serack wrote: Bottom Poster!???!! Arg! I preferred bottom-posting, but in my world, it's just not done. Heh - in the open source world you get your head taken off for it (sigh) >> $base_web_location/// ...\applications\\ or ... \applications \\\? Package-version as the dir name is a bit more traditional, I think. Don't really think it matters - but personally it IS nice to have all your versions in one directory ;) just a nicer way to look at them in my mind >>To further complicate things there is the idea of things in the PHP that script libraries like PEAR and Zend Framework... Ah. Yes.Hmmm. How about ...\libraries\\ for shared 'web libraries' like PEAR. This makes the tree (and increases the necessity for \sites , \applications and \libraries) inetpub ├───applications │ ├───CoApp │ │ ├───Gallery-2.0.7 │ │ └───phpBB-3.0.2 │ └───WordPress │ ├───WordPress-4.3.6 │ └───WordPress-4.3.7 ├───libraries │ ├───Adodb │ │ └───AdoDB-2.5.6 │ └───Zend │ └───ZendFrameworks-2.4.1 └───sites ├───bar.com ├───baz.org └───foo.com Except then you run into things that AREN'T web apps being written in a web language using a library. PHP-GTK and PyGTK scripts, pyrus/pear packaging code, phpunit test suites - they all want to use libraries that aren't necessarily confined to web space. All these dynamic languages make traditional organization pretty hard ;) Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Another kind of package.
On 4/6/2010 4:00 PM, Garrett Serack wrote: ES>> Except then you run into things that AREN'T web apps being written in a web language using a library. ES>> PHP-GTK and PyGTK scripts, pyrus/pear packaging code, phpunit test suites ES>> - they all want to use libraries that aren't necessarily confined to web space. TD>> For libraries, should we have a "Program Files\Shared" type of directory? Similar to the /usr/share on UNIX? Or Libraries? For non-web apps, I had specified a place for common things ( see http://coapp.org/Blueprints/Packages/1._Common_Package_Blueprint ) The pattern works pretty good for shared libraries or components that are designed to be immutable. Zend Frameworks and PEAR libraries really fall into that category. Yeah, I think so too - you don't edit ZF and PEAR , you just use them ;) As long as you can do multiple versions of them sounds good. I'd also argue shared web libraries that are not intended to be modified should install in Program Files\\ like everything else. The only down side is that it's less discoverable, nor is it likely 32-bit / 64-bit specific. (and MS in their infinite wisdom didn't give us a platform-neutral program files directory. That's gonna bite us 10-20 years from now.) I think web libraries which are likely to be subject to some editing/modification should still go in inetpub. I don't think it's really a "web library" if you have to edit it. If you have to change files to make it run, it's an application. And the platform neutral thing has ALREADY bit me in the butt (stupid (x86) at the end of program files) - maybe we just need to always put the neutral stuff in just plain program files sigh Hmmm. Still gonna have to think some more. Oh, and I was going to agree with \ ... it means less repetition, but it's inconsistent with the layout for docs & include folder in the common package blueprint, which I patterned off of unix's way of doing it. I dunno - some things unix doesn't get right in my opinion. Any reason not do to / - so you have wordpress with your 15 million versions inside named wordpress-1.5 and wordpress-2.0 etc etc etc. I know some things DO follow this pattern to some extent (stuff in the gtk stack do this with the includes directories - so you have /gtk/gtk-2.0 etc) Not really that important - just something to ponder. Arglegarble. g hehe - I just want to play with code... really. Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
[Coapp-developers] Another Topic - IRC channel?
Heh - finally another thread on this list. I'm starting to see quite a few members on the mailing list and on launchpad/the wiki Any thoughts to doing a coapp channel on say freenode? I personally really enjoy the interaction and discussions that come up on IRC Any opinions on this? Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Another Topic - IRC channel?
On 4/8/2010 9:41 PM, Garrett Serack wrote: Good Call. Is there an easy way to archive an IRC channel? ... that's the benefit with a mailing list, but yeah, I prefer the immediacy of IRC. Lets set it up. G Freenode is an excellent place for open source projects ;) I'm sitting in #coapp right now Here are the rules for "primary groups" http://freenode.net/primary_groups.shtml At some point we'll need to do the paperwork (ick - do we have a todo list?) I've registered #coapp (I'm auroraeosrose there) hop on and I'll get a list of people who have op access on the channel going and set up (although I sit a lot I hate playing op) See you all there! Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Another Topic - IRC channel?
On 4/8/2010 9:41 PM, Garrett Serack wrote: Good Call. Is there an easy way to archive an IRC channel? ... that's the benefit with a mailing list, but yeah, I prefer the immediacy of IRC. Lets set it up. G As far as archiving conversations, we'd need a bot set up to do logging and we'd need to mention in our topic what that bot is and that it's logging. But that's probably a decision that the people who decide to frequent the channel should make ;) Might be better to simply copy and paste (or get a little bot who will grab a set of lines and publish it somewhere) since sometimes not everything in a channel is useful in a purely project oriented way. Ugh, I'm a bad girl - two posts in a row... Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
[Coapp-developers] IRC Setup Help
On 4/9/2010 3:24 AM, Karthik Rathinavelu wrote: Hi, I haven't used IRC before and I'm new to OpenSource projects... Can you explain on how to start with IRC ? Thanks for the help -- Karthik R No problem in fact I'll CC the list for anyone else who is interested. If you've used any kind of instant messaging (AIM, MSN, Yahoo messenger) then you have kind of an idea of how it works. The first thing you need is an IRC client. There are a LOT of them out there. Personally, since I also have to be on a lot of instant messaging networks, I use pidgin (http://pidgin.im) with the IRC plugins from http://plugins.guifications.org/trac/wiki/PluginPack - note you have to look a bit but they do have windows binaries compiled. For some help choosing clients - http://www.ircreviews.org/clients/ Just pick your operating system and choose from a list. Notice there are 60 (60!) clients listed for windows. Really the most popular ones for windows are either X-Chat or mIRC. So pick a client, download it, install it - so you have an IRC client installed on your machine. Start it up. Each client will be a little bit different on how to create a new connection. You'll need to check out the client's instructions, but the channel for #coapp is located on Freenode http://freenode.net/ which is basically the place that open source projects use for their project related channels ;) You'll need to choose an irc server to connect to - freenode has a list of servers http://freenode.net/irc_servers.shtml but the easiest way to use freenode is to connect to *chat.freenode.net - this is their rotation ip - they'll push you to the closest server with the least number of users (keeps the load nice and balanced) Side note - they're always looking for more servers so if you have the resources So - you connect to chat.freenode.net with your client. On freenode they have the concept of "registered" nicknames. This means the username you choose can be registered to you by being associated with a password, and if other people use it on the network and you log on, you can "get it back". This is useful for keeping track of who is who on IRC. Registration is done via the command **/msg nickserv register * You may run into the issue where your nick is already registered by someone else - then you'll have to change it (use the command /nick name> or if it has not been used in 60 days ask a freenode staffer and they can free it. This means that you probably need to log into freenode at least once every 60 days an identify to keep your name) - more on the subject * http://freenode.net/faq.shtml#nicksetup After you've registered your name you need to do /msg nickserv identify ** every time you log on Some clients support this - but notice this is not the same as the "server password" on many clients. Then you just need to join the channel /join #coapp ** I'll leave you with a few additional places to get more information: http://irchelp.org/irchelp/irctutorial.html - a great tutorial with the basics of IRC http://en.wikipedia.org/wiki/Wikipedia:IRC/Tutorial - wikipedia specific, but just join #coapp as your channel and you don't need to do a host cloak http://fedoraproject.org/wiki/Communicate/IRCHowTo - although project specific, very helpful if you frequent linux or use xchat * If you have any more questions feel free to ask, but I'm not sure if I'll be able to answer any client specific ones (well unless they're pidgin or colloquy ones) Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Conversion to/from UNIX-style build systems?
On 4/9/2010 12:20 PM, Philip Allison wrote: 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. It may simply be too early to expect good answers to this sort of question, but is the plan to somehow piggy-back off of existing build scripts, by - for example - scanning configure.ac, Makefile.am et al and producing at least a skeleton of CoApp build script? This begs for some other questions, such as what *is* a CoApp build script anyway? I assume it is a Visual Studio project file, but I've done very little professional development on the Windows side of the fence. I'm under no illusion that such automatic generation would be simple, since the autotools are notoriously difficult to use "correctly" (with frequent differences of opinion regarding what constitutes correctness), but I also think it would be a mistake to expect developers to maintain multiple build systems; IMHO that is one of the biggest problems with porting as it currently stands. "Shallow forking" presumably entails third parties - people other than the original project developers, perhaps analogous to package maintainers in the Linux world - creating and maintaining CoApp build scripts on a project's behalf, but it strikes me that such work is best done by people who really know the code they're trying to build, and that it goes beyond what I for one would consider the remit of a package maintainer. I'm no expert, but I am currently working on a cross-platform project which makes heavy use of shared libraries and plugins, using the autotools (including libtool) to build using native tools on Linux and MinGW on Windows. The configure.ac and assorted Makefile.am files are not easy to get right, and having to recreate their function from scratch for a different set of tools - then maintain both over time - would be somewhat daunting. Looking forward to your answers, even if the surface can only be scratched at this stage. :) Regards, Phil ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp 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, it's great to see projects that care) Unfortunately you are the minority. What "shallow forks" help solve are projects that DON'T maintain for windows. Projects who don't care. Projects who don't have the developers who know Windows. Projects who don't have the tools to develop for Windows. Or don't want to learn the windows API - who expect windows to work exactly like unix or linux. So while I would love to say "leave such work to be done by people who really know the code they're trying to build" that is simply not feasible for every project. And while the goal would be to push fixes and things upstream to developers - like package maintainers do for linux distributions - the bottom line is not all open source projects take windows patches. How would you address those issues without shallow forks? Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Code?
On 5/17/2010 7:15 PM, Rivera, Rafael wrote: Hey Olaf, Glad to hear you made it home in time! I think last we all spoke, we needed a license before code could be committed. I'm sure that's on Garrett's long TODO list. /rafael On 5/17/2010 5:54 PM, Olaf van der Spek wrote: Hey, Did everybody have a good flight? Turns out I was back just in time, the volcano ashes were over the Netherlands again today. Is there any code in the VCS yet? If so, I can't find it. ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp Yes, last I knew we're waiting on licensing and bzr setup on launchpad for subprojects/places to put code. Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Code?
On 5/17/2010 7:19 PM, Olaf van der Spek wrote: On Tue, May 18, 2010 at 1:15 AM, Rivera, Rafael wrote: Hey Olaf, Glad to hear you made it home in time! I think last we all spoke, we needed a license before code could be committed. I'm sure that's on Garrett's long TODO list. Ok. I remember C was chosen for the engine. What's the rationale behind this decision? C++ seems to make more sense to me. It has no problems with safe strings and memory/resource management. Olaf ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp As we discussed during the summit and is mentioned on the wiki: * Few dependencies * Fast * Small * Binding facilities for most high level languages are common The ability to tie a C library into anything and everything is the biggest reason to use C over C++, using and binding to C++ libraries (especially in most languages - they tend to be written in C) is a real headache - actually beyond a headache, most times it's just a recipe for failure. Thanks, Elizabeth Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Code?
On 5/17/2010 7:36 PM, Olaf van der Spek wrote: On Tue, May 18, 2010 at 1:23 AM, Elizabeth M Smith wrote: As we discussed during the summit and is mentioned on the wiki: Ah, found it. Few dependencies Fast Small Binding facilities for most high level languages are common The ability to tie a C library into anything and everything is the biggest reason to use C over C++, using and binding to C++ libraries (especially in most languages - they tend to be written in C) is a real headache - actually beyond a headache, most times it's just a recipe for failure. C++ can do C bindings as well, can't it? Our bindings should certainly be C. Doesn't C++ share the other advantages? Olaf What? I mean binding coapp to other higher level languages primarily written in C. Perl, Python, PHP, Lua, D etc. and if we write it in C - yes a C++ binding would be easy as well. Thanks, Elizabeth Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Code?
On 5/18/2010 1:31 PM, Garrett Serack wrote: If I thought that we were gaining large leaps in productivity for 50k, I wouldn't have too much of a problem with it. But realistically what does C++ buy us that C doesn't? I'm just saying the delta between C and C++ isn't that much (classes, exceptions, templates, overloading) and we're not dying for those features. I'm actually thinking on the other end a bit. What if we can tighten our belts to< 25k for the core? Would we even bother with a bootstrap dll? Could we get away with embedding the CoApp core with everything? Even if the core chubs out to 60k... perhaps we'd still consider binding that directly into target MSIs. Garrett Serack | Open Source Software Developer | Microsoft Corporation I don't make the software you use; I make the software you use better on Windows. I'm not writing assembly - however if someone else wants to ;) that is all Elizabeth ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Async notification from CoApp Engine (libCoApp)
On 6/9/2010 2:05 PM, Philip Allison wrote: 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 implementation, since they obviously won't be called from the same thread the app's main loop is running in. The "get current status" function means you don't have to care about thread safety in the calling code (unless you want to write a multi-threaded client for other reasons), but obviously the code has to keep polling the library, which can be nasty in and of itself. Or, you have a hybrid model which is either really fantastic and elegant, or a hideous monstrosity - I can't quite decide: optional callback usage, where the default callback (internal to the library) updates the internal structure used by the "get current status" function in a thread-safe fashion. Unless anyone has any good reason to do it another way, I vote callbacks. Regards, Phil ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp CALLBACKS FTW That is all (yes, on my second pot of tea) Thanks, Elizabeth ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] misc
On 6/28/2010 8:39 PM, Rivera, Rafael wrote: Hi Laura, Regarding #2: This came up during the summit and we all agreed there would be a "portable" installation flag/command. This would allow you to deploy an application to a custom location, like a USB flash memory. Surprise! :) /rafael On 6/28/2010 7:11 PM, m...@distasis.com wrote Second topic, was about installing software. I remember reading on the wiki that the installer would use the MSI format. Not that familiar with the format (usually prefer zip files and tarballs). However, can't help wondering how applications like portable apps (programs that run on removable drives or flash drives) will fit into the picture. Removable drives fill a nice niche between cloud computing and having everything local to one machine. You can take your programs and data with you anywhere to any Windows system and work. If the install program ends up tying a program to the registry or expecting it to be on a particular drive at all times, it'll make it difficult to use the applications provided by CoAPP as portable apps. It would be nice if CoAPP could host portable apps alongside regular applications that tie in to the registry and use helpful Windows features like defaulting file extensions to a particular program. Has any thought about how to handle a typical portable app (a program that's meant to be installed to a flash drive or removeable drive) within the project? ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp And we should have written that down on the wiki (oops) - although I believe it was mentioned in the summit notes. Because of the position of the project as a member of Codeplex foundation - contributing to the actual client tools and developer tools will need to remain under CLA - this is no different then apache foundation projects. However contributing to other projects to make them work with and cooperate with Coapp is an entirely different story - patches going to other projects will need to be under the project's license. I'm not sure if there has been talk about documentation licensing, but I agree that it needs to be stated what licensing the documentation is released under, that it should NOT be the same as the source code (that leads to a mess of trouble) and that it should never be in the actual source code files (I've run into SUCH headaches with that). As for me I don't really care what license is used for the documentation, just something that is more suited to written text instead of code. Documentation is the most overlooked part of the project and often the most important so who wants to write that wiki page on portable application support ... Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Code release schedule
This is why I simply set my email to view only text and send only text - even if someone sends html email I just don't see it ;) Oh, and three million quotes if the conversation isn't relevant drives me up a wall - I can go view a thread in the archives, don't need the whole thread in every email. In other news - how come we have all these mails about this and none about actual code On an actual relevant thing. Release Schedules: 1. Will dev tools and client tools ever have separate releases? 2. Are we going to have some sort of release process in place? 3. What about pre-release testing/process? 4. Will Garrett kill me for not committing my work because Bazaar is killing me 5. Where is my hg->bzr plugin... Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Precompiled Headers
On 7/28/2010 1:33 PM, Garrett Serack wrote: Does anyone **REALLY** find that precompiled headers are worth the $%*(ing headaches? I'm considering turning them all off and removing the foolish stdafx crap from the C/C++ projects. Frankly, in my opinion PCs are fast enough to deal with a bit of headerfiles these days, and there isn't an appreciable benefit these days. G Please Please turn them off (actually I think I already did locally) Thanks, Elizabeth ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Engine - Teds initial take
On 8/4/2010 11:13 AM, Rivera, Rafael wrote:
Looks nice, love the chip name.
Just one note -- I see wide-character strings in use. I suggest
replacing them, and their print functions, with T equivalents, leaving
the choice of ANSI or UNICODE to the magical defines in the headers and
ultimately the human compiling this stuff.
So, from initial glance, I'd replace L"" with _T("") and fwprintf with
_ftprintf.
No way in hell do I want to support anyone doing that - then you'd have
idiots compiling and giving out version that don't support UNICODE
strings and users complaining about it
ICK
UNICODE or nothing.
Thanks,
Elizabeth M Smith
___
Mailing list: https://launchpad.net/~coapp-developers
Post to : coapp-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Questions, Questions, Questions
On 8/12/2010 9:18 PM, Garrett Serack wrote: We're NEVER GONNA UPGRADE using MSI. NEVER. Windows Installer fucked this up, and we're not gonna follow. We always want it physically possible to have two versions installed. This is the secret sauce to "No Reboots. Fucking Ever." :D G Heh - this may get REALLY fun when you get to say... a database or a web app with data lying around... Are we going to provide some way to migrate that data during an "upgrade" - cause if not we'll have some pretty angry users. "My mysql upgraded and all my data is gone..." Sigh.... (generic windows users) Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Questions, Questions, Questions
On 8/13/2010 10:37 AM, Olaf van der Spek wrote: On Fri, Aug 13, 2010 at 1:20 PM, Elizabeth M Smith wrote: Heh - this may get REALLY fun when you get to say... a database or a web app with data lying around... Are we going to provide some way to migrate that data during an "upgrade" - cause if not we'll have some pretty angry users. "My mysql upgraded and all my data is gone..." Why would the data be gone after a MySQL upgrade? Olaf . I was referring to the fact that by default the data directory for mysql installs is in the application directory So if you didn't "upgrade" but instead installed both side by side, it would have a new blank data directory And the user, thinking they've simply upgraded and not done a new install would be utterly confused. Just making sure that even if our "upgrades" are side by side that we have a way to migrate user settings and data for applications. Thanks, Elizabeth M Smith ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Questions, Questions, Questions
On 8/13/2010 11:17 AM, Olaf van der Spek wrote: On Fri, Aug 13, 2010 at 5:14 PM, Elizabeth M Smith wrote: I was referring to the fact that by default the data directory for mysql installs is in the application directory So if you didn't "upgrade" but instead installed both side by side, it would have a new blank data directory And the user, thinking they've simply upgraded and not done a new install would be utterly confused. Just making sure that even if our "upgrades" are side by side that we have a way to migrate user settings and data for applications. Wasn't it changed to some stupid location like All Users some time ago? The data dir is specified by the conf file and I'm sure our intend is to not lose the conf file. ;) Olaf The point I was trying to make is that other applications will have similar issues and not all are smart enough to have a conf file to specify it (and what if the user changes the location?) - we need some kind of way for the "upgrade" to specify migration data if we're not doing in place upgrades. Thanks, Elizabeth ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Engine APIs required by Bootstrap
On 9/1/2010 12:16 PM, Olaf van der Spek wrote: On Wed, Sep 1, 2010 at 3:53 PM, Philip Allison wrote: Is __int64 the most preferred type for large file support? Having had to I'd use long long. Olaf ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp Um... there is no long long on windows ^-^; Thanks, Elizabeth ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
Re: [Coapp-developers] Engine APIs required by Bootstrap
On 9/1/2010 1:17 PM, William A. Rowe Jr. wrote: On 9/1/2010 11:58 AM, Olaf van der Spek wrote: On Wed, Sep 1, 2010 at 6:55 PM, Garrett Serack wrote: knowing that 64bits is plenty enough for file sizes, I think we should standardize on __int64 where we can. __int64 is reasonable, although long long is standard. Not per _ftelli64/_fseeki64 etc. Or are you looking somewhere else? ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp Why not just use the native windows API file functions instead of the C runtime versions - this is definitely a windows only product and the C runtime versions are wrappers - what are we gaining? Thanks, Elizabeth ___ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
