Enso win32 binaries for download
14 views
Skip to first unread message
blackdaemon
Feb 20, 2009, 10:56:06 AM2/20/09
to Enso Developers
Hi
I uploaded Enso win32 binaries for you who do not want to bother with
compilation.
These are compiled for Python 2.5. It is tested, but there is always
room for mistakes,
so please let me know if something is not working.
Just extract the archive into the root of Enso directory:
http://blackdaemon.no-ip.org/wiki/_media/projects:enso:enso-community-binaries-win32.zip
Built on Windows XP SP2, MS VisualStudio 2008 SDK, Python 2.5.
~bd
I uploaded Enso win32 binaries for you who do not want to bother with
compilation.
These are compiled for Python 2.5. It is tested, but there is always
room for mistakes,
so please let me know if something is not working.
Just extract the archive into the root of Enso directory:
http://blackdaemon.no-ip.org/wiki/_media/projects:enso:enso-community-binaries-win32.zip
Built on Windows XP SP2, MS VisualStudio 2008 SDK, Python 2.5.
~bd
Timothy Biron
Feb 22, 2009, 10:56:06 AM2/22/09
to enso-de...@googlegroups.com
I tried to download the binaries today so that I can test them with your branch that is proposed for merging. But, firefox keeps saying the server is taking to long to respond. I tried going to the compilation route, but to install MS VS 2008 SDK you need at least MS VS 2008 Standard Edition installed first, which is not free and I wasn't going to pay $250.
It seems like there are some issues still with the Windows build process. While we should just be able to use the binaries that blackdaemon has provided as long as no changes need to be made to the code, contributors should still be able to modify any part of the code base without having to buy the tools to build their changes or have someone else build for them. The MS Visual Studio dependancy needs to disappear. I think we either need to put more resources behind getting an all Python version working and just use the binaries we have while that project is ongoing or get another team going to see if we could get it to build with MinGW. MinGW takes GCC compilation flags and because it already uses SCons to build, getting MinGW to work should only require getting the correct set of compilation flags.
It seems like there are some issues still with the Windows build process. While we should just be able to use the binaries that blackdaemon has provided as long as no changes need to be made to the code, contributors should still be able to modify any part of the code base without having to buy the tools to build their changes or have someone else build for them. The MS Visual Studio dependancy needs to disappear. I think we either need to put more resources behind getting an all Python version working and just use the binaries we have while that project is ongoing or get another team going to see if we could get it to build with MinGW. MinGW takes GCC compilation flags and because it already uses SCons to build, getting MinGW to work should only require getting the correct set of compilation flags.
blackdaemon
Feb 22, 2009, 12:00:47 PM2/22/09
to Enso Developers
Sorry for not being precise here, what I have used is the
"Windows SDK for Windows Server 2008 and .NET Framework 3.5" where I
am not aware of any dependency on any other paid MS software, see the
download page / release notes:
http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en
I think also using MS Visual Studio Express tools which are free,
would be possible.
Anyway, I agree that being able to compile win32 frontend using
MinGW tools is more than preferable.
I am still quite skeptic though about going the "rewrite win32
platform stuff into pure Python" route. There is still some low-level
stuff that is hard to do in Python itself (system wide key hooks?), so
we probably end up having need for some C code -> DLL anyway...
There are mirrored win32 binaries:
http://www.box.net/shared/qyqovqt199
~bd
On Feb 22, 4:56 pm, Timothy Biron <timothybi...@gmail.com> wrote:
> I tried to download the binaries today so that I can test them with your
> branch that is proposed for merging. But, firefox keeps saying the server
> is taking to long to respond. I tried going to the compilation route, but
> to install MS VS 2008 SDK you need at least MS VS 2008 Standard Edition
> installed first, which is not free and I wasn't going to pay $250.
>
> It seems like there are some issues still with the Windows build process.
> While we should just be able to use the binaries that blackdaemon has
> provided as long as no changes need to be made to the code, contributors
> should still be able to modify any part of the code base without having to
> buy the tools to build their changes or have someone else build for them.
> The MS Visual Studio dependancy needs to disappear. I think we either need
> to put more resources behind getting an all Python version working and just
> use the binaries we have while that project is ongoing or get another team
> going to see if we could get it to build with MinGW. MinGW takes GCC
> compilation flags and because it already uses SCons to build, getting MinGW
> to work should only require getting the correct set of compilation flags.
>
"Windows SDK for Windows Server 2008 and .NET Framework 3.5" where I
am not aware of any dependency on any other paid MS software, see the
download page / release notes:
http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en
I think also using MS Visual Studio Express tools which are free,
would be possible.
Anyway, I agree that being able to compile win32 frontend using
MinGW tools is more than preferable.
I am still quite skeptic though about going the "rewrite win32
platform stuff into pure Python" route. There is still some low-level
stuff that is hard to do in Python itself (system wide key hooks?), so
we probably end up having need for some C code -> DLL anyway...
There are mirrored win32 binaries:
http://www.box.net/shared/qyqovqt199
~bd
On Feb 22, 4:56 pm, Timothy Biron <timothybi...@gmail.com> wrote:
> I tried to download the binaries today so that I can test them with your
> branch that is proposed for merging. But, firefox keeps saying the server
> is taking to long to respond. I tried going to the compilation route, but
> to install MS VS 2008 SDK you need at least MS VS 2008 Standard Edition
> installed first, which is not free and I wasn't going to pay $250.
>
> It seems like there are some issues still with the Windows build process.
> While we should just be able to use the binaries that blackdaemon has
> provided as long as no changes need to be made to the code, contributors
> should still be able to modify any part of the code base without having to
> buy the tools to build their changes or have someone else build for them.
> The MS Visual Studio dependancy needs to disappear. I think we either need
> to put more resources behind getting an all Python version working and just
> use the binaries we have while that project is ongoing or get another team
> going to see if we could get it to build with MinGW. MinGW takes GCC
> compilation flags and because it already uses SCons to build, getting MinGW
> to work should only require getting the correct set of compilation flags.
>
> On Fri, Feb 20, 2009 at 10:56 AM, blackdaemon <pavelvi...@gmail.com> wrote:
>
> > Hi
>
> > I uploaded Enso win32 binaries for you who do not want to bother with
> > compilation.
> > These are compiled for Python 2.5. It is tested, but there is always
> > room for mistakes,
> > so please let me know if something is not working.
>
> > Just extract the archive into the root of Enso directory:
>
> >http://blackdaemon.no-ip.org/wiki/_media/projects:enso:enso-community...
>
> > Hi
>
> > I uploaded Enso win32 binaries for you who do not want to bother with
> > compilation.
> > These are compiled for Python 2.5. It is tested, but there is always
> > room for mistakes,
> > so please let me know if something is not working.
>
> > Just extract the archive into the root of Enso directory:
>
Stuart Langridge
Feb 22, 2009, 12:02:50 PM2/22/09
to enso-de...@googlegroups.com
> There are mirrored win32 binaries:
> http://www.box.net/shared/qyqovqt199
> http://www.box.net/shared/qyqovqt199
Coolness. I'm not a Windows person, so: when you get this file, is
there an installer in it? Could you write up some instructions on the
wiki as to how to install Enso given these binaries? We need a "how to
install Enso" page (which should later become nice and dynamic and
detect your platform, etc), and this is a great start.
sil
--
New Year's Day --
everything is in blossom!
I feel about average.
-- Kobayashi Issa
Timothy Biron
Feb 22, 2009, 12:26:00 PM2/22/09
to enso-de...@googlegroups.com
Stuart,
Looking at the file it currently is just a zip file that will place the binaries in the correct folders when you extract it. So, currently the Windows version would still be just for development use. But, I am sure an actual installer wouldn't be to difficult to accomplish.
Looking at the file it currently is just a zip file that will place the binaries in the correct folders when you extract it. So, currently the Windows version would still be just for development use. But, I am sure an actual installer wouldn't be to difficult to accomplish.
Timothy Biron
Feb 22, 2009, 12:46:38 PM2/22/09
to enso-de...@googlegroups.com
Thanks. I've downloaded the binaries. I'm going to try and test them out sometime today.
The clarification on the Windows SDK was a big help. I'll attempt to setup an environment to see what exactly is needed to build the binaries so that we can document that well.
As for an all Python version, it may be useful to see if it could be accomplished. The pyhook (http://pyhook.wiki.sourceforge.net/) project would take care of the system wide key hook issue you have brought up. I think the main thing getting an all python version is that binaries already exist for things like Cairo and PyCairo for every platform, why do we need to compile them ourselves? I haven't taken an indepth look into the Enso code at all, so I may be missing something on the importance of compiling these ourseleves. Please let me know if I'm way off on this.
The clarification on the Windows SDK was a big help. I'll attempt to setup an environment to see what exactly is needed to build the binaries so that we can document that well.
As for an all Python version, it may be useful to see if it could be accomplished. The pyhook (http://pyhook.wiki.sourceforge.net/) project would take care of the system wide key hook issue you have brought up. I think the main thing getting an all python version is that binaries already exist for things like Cairo and PyCairo for every platform, why do we need to compile them ourselves? I haven't taken an indepth look into the Enso code at all, so I may be missing something on the importance of compiling these ourseleves. Please let me know if I'm way off on this.
blackdaemon
Feb 22, 2009, 1:11:40 PM2/22/09
to Enso Developers
@Stuart
As TImothy said, you just need to extract the files to Enso directory
and it should then be possible to run it normally.
Actually I have quite usable Enso setup on my machine currently, with
essential commands like open, learn as, multimedia commands, window
management, bookmarks, etc.
I still have to make this available as branch either on git or bazar
iin launchpad. But as I am quite struggling to handle basic git usage
recently (is it only me? git is so powerful but so hard to grasp and
not make fool mistakes all the time) my branches are not in a good
shape to be pushed public right now.
So said that, I have been thinking about creating win32 Enso package
from my setup using NSIS installer. That would help people who wants
just produce useful commands, until we
manage to get buildable code from repo.
What do you think? Is that worth the effort?
@Timothy
Yes I think you are correct about Cairo stuff, as far as I have
been browsing the code, there is nothing very special in cairo
part. I do not know how good PyHook can handle things, but
I will take a look into it.
~bd
On Feb 22, 6:46 pm, Timothy Biron <timothybi...@gmail.com> wrote:
> Thanks. I've downloaded the binaries. I'm going to try and test them out
> sometime today.
>
> The clarification on the Windows SDK was a big help. I'll attempt to setup
> an environment to see what exactly is needed to build the binaries so that
> we can document that well.
>
> As for an all Python version, it may be useful to see if it could be
> accomplished. The pyhook (http://pyhook.wiki.sourceforge.net/) project
> would take care of the system wide key hook issue you have brought up. I
> think the main thing getting an all python version is that binaries already
> exist for things like Cairo and PyCairo for every platform, why do we need
> to compile them ourselves? I haven't taken an indepth look into the Enso
> code at all, so I may be missing something on the importance of compiling
> these ourseleves. Please let me know if I'm way off on this.
>
As TImothy said, you just need to extract the files to Enso directory
and it should then be possible to run it normally.
Actually I have quite usable Enso setup on my machine currently, with
essential commands like open, learn as, multimedia commands, window
management, bookmarks, etc.
I still have to make this available as branch either on git or bazar
iin launchpad. But as I am quite struggling to handle basic git usage
recently (is it only me? git is so powerful but so hard to grasp and
not make fool mistakes all the time) my branches are not in a good
shape to be pushed public right now.
So said that, I have been thinking about creating win32 Enso package
from my setup using NSIS installer. That would help people who wants
just produce useful commands, until we
manage to get buildable code from repo.
What do you think? Is that worth the effort?
@Timothy
Yes I think you are correct about Cairo stuff, as far as I have
been browsing the code, there is nothing very special in cairo
part. I do not know how good PyHook can handle things, but
I will take a look into it.
~bd
On Feb 22, 6:46 pm, Timothy Biron <timothybi...@gmail.com> wrote:
> Thanks. I've downloaded the binaries. I'm going to try and test them out
> sometime today.
>
> The clarification on the Windows SDK was a big help. I'll attempt to setup
> an environment to see what exactly is needed to build the binaries so that
> we can document that well.
>
> As for an all Python version, it may be useful to see if it could be
> accomplished. The pyhook (http://pyhook.wiki.sourceforge.net/) project
> would take care of the system wide key hook issue you have brought up. I
> think the main thing getting an all python version is that binaries already
> exist for things like Cairo and PyCairo for every platform, why do we need
> to compile them ourselves? I haven't taken an indepth look into the Enso
> code at all, so I may be missing something on the importance of compiling
> these ourseleves. Please let me know if I'm way off on this.
>
> On Sun, Feb 22, 2009 at 12:00 PM, blackdaemon <pavelvi...@gmail.com> wrote:
>
> > Sorry for not being precise here, what I have used is the
> > "Windows SDK for Windows Server 2008 and .NET Framework 3.5" where I
> > am not aware of any dependency on any other paid MS software, see the
> > download page / release notes:
>
> >http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74...
>
> > Sorry for not being precise here, what I have used is the
> > "Windows SDK for Windows Server 2008 and .NET Framework 3.5" where I
> > am not aware of any dependency on any other paid MS software, see the
> > download page / release notes:
>
Stuart Langridge
Feb 22, 2009, 1:49:20 PM2/22/09
to enso-de...@googlegroups.com
> So said that, I have been thinking about creating win32 Enso package
> from my setup using NSIS installer. That would help people who wants
> just produce useful commands, until we
> manage to get buildable code from repo.
> from my setup using NSIS installer. That would help people who wants
> just produce useful commands, until we
> manage to get buildable code from repo.
Absolutely useful, yes. Ordinary Windows users will need an installer.
You should create a folder in the code to store the build scripts/NSIS
scripts in, so everything required to build is in the repository.
shu.chen
Feb 22, 2009, 5:58:25 PM2/22/09
to Enso Developers
How are you windows developers working on Enso in terms of IDE and bzr
setup? I'm trying to get Eclipse set up and I've been having a lot of
issues making a branch with the BzrEclipse plugin. Might be because I
have the Win32 native bzr package, or might be Python 2.6 causing the
issues. I'm installing cygwin now (the bzr people recommend that over
the native win .exe) but wanted to get some ideas from you guys set
your working environment.
~Shu
setup? I'm trying to get Eclipse set up and I've been having a lot of
issues making a branch with the BzrEclipse plugin. Might be because I
have the Win32 native bzr package, or might be Python 2.6 causing the
issues. I'm installing cygwin now (the bzr people recommend that over
the native win .exe) but wanted to get some ideas from you guys set
your working environment.
~Shu
blackdaemon
Feb 22, 2009, 7:50:08 PM2/22/09
to Enso Developers
Shu,
I am using PyDev, and git/bzr over Cygwin command-line, this proved as
best solution at the moment. JGit Eclipse plugin is still not in ready-
to-use state and I didn't tried Bazar Eclipse plugin as I had problems
installing native win32 bzr.
~bd
I am using PyDev, and git/bzr over Cygwin command-line, this proved as
best solution at the moment. JGit Eclipse plugin is still not in ready-
to-use state and I didn't tried Bazar Eclipse plugin as I had problems
installing native win32 bzr.
~bd
Dj Gilcrease
Feb 23, 2009, 2:59:43 AM2/23/09
to enso-de...@googlegroups.com
On Sun, Feb 22, 2009 at 11:11 AM, blackdaemon <pavel...@gmail.com> wrote:
> Yes I think you are correct about Cairo stuff, as far as I have
> been browsing the code, there is nothing very special in cairo
> part. I do not know how good PyHook can handle things, but
> I will take a look into it.
> Yes I think you are correct about Cairo stuff, as far as I have
> been browsing the code, there is nothing very special in cairo
> part. I do not know how good PyHook can handle things, but
> I will take a look into it.
PyHook is fairly easy to use, I have a repository where I have started
the process of moving everything to pure python (I basicly just
changed out the code in the platform/win32 directory with the one in
the linux directory, then started modifying the code to remove Xlib
and replace it with pyHook and other components
lp:~digitalxero/enso/win32refector
Yes I spelled refactor wrong, but didnt notice till it was created and
too lazy to fix it.
Requirements added;
pygtk
win32all
pyhooks
python-cairo
Sendkeys ( http://www.rutherfurd.net/python/sendkeys/index.html )
The last requirement I am not sure if I will keep it, just kinda
playing to see if it would fit my needs
Right now if you run enso/platform/win32/input/__init__.py it executes
a test mode that captures the capslock key and prints out when it
should be entering/exiting Quazi mode, and prints anything you type
while holding down the caps key (typing exit ends the test). This
section will need more work once I get the selection code working and
such, but I needed my proof of concept before I started working on it
more
I just started working on the selection code, but have not had much
time in the past two weeks to get a proof of concept test written for
it
F4CIO
Feb 1, 2017, 10:06:24 AM2/1/17
to Enso Developers
I am late to the party but for future readers:
ENSO+ is a stand-alone open source version for Windows written in .Net with installer included.
http://www.f4cio.com/ensoplus.aspx
ENSO+ is a stand-alone open source version for Windows written in .Net with installer included.
http://www.f4cio.com/ensoplus.aspx
Aza
Feb 3, 2017, 6:52:15 PM2/3/17
to Enso Developers
How awesome!
--
You received this message because you are subscribed to the Google Groups "Enso Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enso-develope...@googlegroups.com.
To post to this group, send email to enso-de...@googlegroups.com.
Visit this group at https://groups.google.com/group/enso-developers.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages