It was long time I didn't posted here. Fresh IDE is already v2.1.2 and is more powerful than ever before. :)
At the end I managed to implement a code completion for the local labels (what was needed feature since the day one of the project) and several other features useful for working with big projects.

You can download the latest Fresh IDE from its download page.

BTW, the fresh main site is updated to use assembly written engine instead of php.

Also, Fresh IDE has page on freecode.com (the former "freshmeet")

Posted on 2012-11-10 11:20:25 by JohnFound
If you can get Fresh working under Linux without forcing me to install wine. (eg. 3.0 ;) ) Then I'll be willing to give FASM another test run.. it has been a few years since I last looked at it.
Posted on 2012-11-10 21:09:31 by Synfire

If you can get Fresh working under Linux without forcing me to install wine. (eg. 3.0 ;) ) Then I'll be willing to give FASM another test run.. it has been a few years since I last looked at it.


Well, yes, you simply have to wait a little (or more) for version 3.0 which is planned to be portable. Also you may not wait, but help the project to reach this milestone. ;)
Posted on 2012-11-10 23:27:35 by JohnFound
Well, yes, you simply have to wait a little (or more) for version 3.0 which is planned to be portable.


Sorry, I assume I misunderstood your website. It seemed as though you were closing in on a 3.0 release soon. Totally my fault. I'll just continue using gEdit & NASM until Fresh IDE 3.0 becomes available. I am happy to hear that Linux is still on the todo list.

Also you may not wait, but help the project to reach this milestone. ;)


Except that it's designed using an assembler that I don't currently use, or have any use for. The only reason for my interest in FASM at all was the idea that I might have an IDE with auto-completion and argument hints specifically for my Linux/ASM projects.

In any event, congrats on the new version!
Posted on 2012-11-11 08:02:22 by Synfire
I am happy to hear that Linux is still on the todo list.


You also missed (and it is probably my fault to explain it on the Fresh site) - Linux is not the only target - I am focused now on development of library for portable assembly programming - FreshLib - that will allow one to create portable assembly language programs and to compile them for different OSes (x86 of course) from one single source.

The work on FreshLib is in progress now - it supports Win32, Linux and partially KolibriOS. It is possible to create console applications for these OSes and very simple GUI applications. (For example the CMS of the Fresh main site - MiniMagAsm is created using FreshLib and can be compiled for Windows and for Linux from the same source.

FreshLib contains very small OS dependent layer, so porting it to any other OS is very fast and easy.

Fresh IDE (even now) is based on FreshLib, especially the non-GUI parts. Unfortunately FreshLib still misses the advanced GUI features, needed by Fresh IDE...
Posted on 2012-11-11 10:49:40 by JohnFound
Good luck with the idea of a cross platform assembler, it should be so easy! But it isnt. I would love to see you be the first!
Posted on 2012-11-12 07:42:49 by Homer
The concept of "cross platform" assembler is not different than "cross platform" C for example. The answer is "libraries" and "abstraction layers".
The big advantage of assembly is that its layers becomes more light and controllable than the HLL layers, which tends to become real "Lasagna code" made of many, fat layers of code. :D
Posted on 2012-11-12 09:51:11 by JohnFound
I don't know how crazy you want to get but with a properly designed abstraction layer you could achieve the following:

        FreshIDE
            |
        FreshLib
          /  |  \
        /    |    \
      GTK+  QT  wxWidgets
        |    |    |
_____________________________
  |      |      |      |
Linux  *BSD  Windows  OSX


Of course, an easier and quicker alternative is to simply pick just one portable GUI library and use it!  :lol:
Posted on 2012-11-12 11:11:22 by p1ranha

I don't know how crazy you want to get but with a properly designed abstraction layer you could achieve the following:

        FreshIDE
            |
        FreshLib
          /  |  \
        /    |    \
      GTK+  QT  wxWidgets
        |    |    |
_____________________________
  |      |      |      |
Linux  *BSD  Windows  OSX

Of course, an easier and quicker alternative is to simply pick just one portable GUI library and use it!  :lol:


I also planned something similar. But all these Qt, GTK, etc. was rejected, because they are over-bloated and totally not suitable for assembly programming. "Light" widget toolkits are actually not so "light". Also some of the target platforms has no these toolkits ported - for example KolibriOS.

The architecture of FreshLib is simple - it is based on two layers:
1. OS dependent layer - it gives only the very basic functionality needed by the library - for example opening and read a file, creating simple window, basic memory management, basic network support, system events processing etc.

2. OS independent layer - contains the main functionality of the library - complex data processing (dynamic arrays and strings for example), graphics, GUI widgets etc.
This layer is relatively big, but it is only one for all platforms.

From the external libraries, FreshLib uses only the minimum:
On Linux: libc, libX and pthreads (with some tendency to use only syscalls later)
On Windows: Win32 API
On KolibriOS: Combination of system calls and FreshLib code.
Posted on 2012-11-12 11:35:27 by JohnFound
I also planned something similar. But all these Qt, GTK, etc. was rejected, because they are over-bloated and totally not suitable for assembly programming. "Light" widget toolkits are actually not so "light".


There is some truth to what you say here. However, the "weight" of these toolkits actually decrease exponentially if your system uses multiple applications based on the same library. As far as statically linked applications go, a well written assembler language library is definitely preferred for the obvious reasons. But when you are talking about systems like Linux and BSD, most of the graphical applications you find are dynamically linked. What's more, there are already a great deal of users of these graphical toolkits and it is very likely that you will have more than one application which depend on these toolkits.

Also some of the target platforms has no these toolkits ported - for example KolibriOS.


This is a very good point. So instead of trying to design GTK into your framework, what might be a good idea is to abstract away the high level toolkits themselves. You would only need to provide system dependent features to architectures which aren't currently supported by the toolkit. As the toolkit itself grows to support the new systems, it just means adding an optional flag to disable the system dependent stuff.

The idea here is that your abstraction layer becomes fairly static, your user base would rarely need to change their own source. At the same time, you'll be able to take advantage of toolkits already established on many of the target systems.

The architecture of FreshLib is simple - it is based on two layers:
1. OS dependent layer - it gives only the very basic functionality needed by the library - for example opening and read a file, creating simple window, basic memory management, basic network support, system events processing etc.

2. OS independent layer - contains the main functionality of the library - complex data processing (dynamic arrays and strings for example), graphics, GUI widgets etc.
This layer is relatively big, but it is only one for all platforms.


Sounds like a very sane layout. I remember a guy that used to hang out here (I think his username was 'vid' or something like that), he was using a similar structure to try and create a library that could build across multiple assemblers, I think he gave up or ended up focusing only on a single assembler.

From the external libraries, FreshLib uses only the minimum:
On Linux: libc, libX and pthreads (with some tendency to use only syscalls later)
On Windows: Win32 API
On KolibriOS: Combination of system calls and FreshLib code.


Again, your layout looks nice. My issue would still be with the linux libX. Your argument about not all targets supporting Gtk and friends is the same with libX. Not all Linux systems support libX for their graphical environments. Aside from the fact that there are multiple X systems (Xorg, XFree, KDrive, etc) there are also an increasing number of people running desktop environments on fbdev and svgalib to reduce the overall system size. So for the greatest amount of portability across different Linux configurations, you'd still be better off using the higher level abstractions like GTK & friends which already handle these configurations.

P.S.
The only reason I refer to GTK so much rather than QT or the others out there is because when I played around with graphical assembly programming under linux, I found GTK to be the easiest to work with from a lower level. Of course that was GTK 2.x series and I haven't had a chance to play around with the GTK 3.x branch, so I can't really vouch for it. Downside is that it introduces the LGPL into your codebase and I'm not really a big fan of the GPL branch of licenses.
Posted on 2012-11-12 13:02:31 by Synfire
"Weight" is not the size on the disk, or executable size or load time. A huge, memory hungry  library, mapped and executed in the address space of your application can make miracles with the performance and responsiveness of even well optimized assembly application. :D

GTK, Qt and the family are resource hungry monsters and I am sure they have nothing to do with assembly programming. If there was an assembly written toolkit, I would be happy to use it and to spend some effort. But such a toolkit does not exists, so it have to be created - the GUI part of FreshLib is aimed to be such assembly written toolkit.

P.S. The library of Vid is named FASMLIB and is really good portable library for several assemblers and OSes. Unfortunately FASMLIB does not contains GUI part and also, it seems Vid stopped to work on this project (I hope temporary).
BTW, the portable heap manager of FreshLib is based on the heap manager of FASMLIB.
Posted on 2012-11-12 13:39:01 by JohnFound
So you have decided to replicate the functionality of a cross-platform GUI library such as GTK or QT but using your own assembly code interface?
That's a BIG task if your goal is to support Linux, and Windows, and etc..
But if that's your itch, scratch at it.  :lol:
Posted on 2012-11-12 19:30:40 by p1ranha

So you have decided to replicate the functionality of a cross-platform GUI library such as GTK or QT but using your own assembly code interface?
That's a BIG task if your goal is to support Linux, and Windows, and etc..
But if that's your itch, scratch at it.  :lol:


As I said, in my opinion, these toolkits are bloated, so it is not necessary to duplicate all of its functionality. I am practical - my goal is to have enough functionality in order to implement Fresh IDE in portable manner. You can test it and evaluate how complex is this task. In this very moment the problem is only in the absence of 4..5 (not very simple) widgets.

P.S. Note that programming big projects with Fresh IDE is really very, very productive, so I hope the project will reach these goals in acceptable time.
Posted on 2012-11-12 22:54:15 by JohnFound

As I said, in my opinion, these toolkits are bloated, so it is not necessary to duplicate all of its functionality.


I think you're missing the forest for the trees.  For most Linux/*BSD desktops these libraries are ALREADY installed on most of your target end-users machines.  I'm not sure about OSX though.  Any assembly programmer worth his or her salt can quite easily install the required library package if the needed dependency is missing.


P.S. Note that programming big projects with Fresh IDE is really very, very productive, so I hope the project will reach these goals in acceptable time.


When you get to the point you can support Linux I'll be more than happy to test-drive it.  8)
Posted on 2012-11-13 11:20:43 by p1ranha