On Sat, Oct 13, 2018 at 09:51:53AM +0800, Ben Coman wrote:
> Note that git branches are simply pointers to a particular commit hash.
> There is no computational link between the "branch name" in your repo
> and the "branch name" in the target repo.
Thanks Ben and Alistair. I'll experiment and
On Wed, Oct 17, 2018 at 10:08:58AM +0200, Michel Onoff wrote:
> Specifically, I'm trying to build on all supported platforms, namely macOS,
> Windows and Linux. Currently I've got Linux and Windows under control, but I
> cannot find a systematic way to build on macOS.
When I last tried either on
ok good to know its fixed, thanks Peter.
On Wed, Oct 17, 2018 at 10:29 PM Peter Uhnak wrote:
> Yes, this is fixed in P7
> https://pharo.fogbugz.com/f/cases/20212#BugEvent.193460
>
> solution is to close your image and open again, or go to process browser
> and kill the new UI loop that started.
Yes, this is fixed in P7
https://pharo.fogbugz.com/f/cases/20212#BugEvent.193460
solution is to close your image and open again, or go to process browser
and kill the new UI loop that started.
As a workaround you can do parseExpression:onError: (or whatever the name
is)... or I've made a small
Le 17/10/2018 à 07:36, H. Hirzel a écrit :
The successor of Ni is 'Spry'
https://github.com/gokr/spry
http://sprylang.se/
"Spry borrows homoiconicity from Rebol and Lisp, free form syntax from
Forth and Rebol, the word of different types from Rebol, good data
structure literal support from
If I do something normal in the Playground like
RBParser parseExpression: 'bac' and inspect it , it works fine
If I do something like
RBParser parseExpression: 'bac->'. Then it displays an error and things
really get weird
I get redraw problems with Morphic(if I start moving windows around),
Chris,
That is not what I am seeing in Pharo 7:
date1 := Date today.
date2 := Date today translateToUTC.
date1 = date2. "false"
date1 hash = date2 hash. "false"
dictionary := Dictionary new.
dictionary at: date1 put: date1.
dictionary at: date2 put: date2.
(dictionary at: date1) = date1.
Sven Van Caekenberghe-2 wrote
>> the obvious way to introduce it would
>> have been to introduce a new DateInZone class.
Yes, that would have been nice. Especially since IMHO this is the more
common, simple case, and least surprising to new users. I would assume by
the time you're building
Hi,
On Tue, Oct 16, 2018 at 1:28 PM Alistair Grant
wrote:
> Hi Petr,
>
> On Tue, 16 Oct 2018 at 21:25, Petr Fischer via Pharo-users
> wrote:
> >
> > My problem - use Dates as Dictionary keys - shortly:
> >
> > d1 := Date today translateToUTC.
> > d2 := Date today.
> >
> > d1 = d2. (true!)
>
>
no I wont be introducing new syntax, I rather keep this 100% smalltalk.Also
LowTalk uses GC which is a no go for me.
this is the "syntax" I am considering so its fully compatible with Pharo
--
SomeClass >> helloWorld: aMessage
#(char* aMessage
Perhaps a C-syntax front-end for Lowtalk would be interesting?
http://forum.world.st/Re-ANN-Lowtalk-a-new-Smalltalk-dialect-that-could-eventually-replace-Slang-td4966907.html
cheers -ben
On Wed, 17 Oct 2018 at 19:37, Dimitris Chloupis
wrote:
> there will be no remap of variable names, this is
there will be no remap of variable names, this is a strict compiler if you
can even call it a compiler. Your variable names will stay exactly the same
in the C side , a concern here was that Pharo would not allow to have names
like "my_personal_function". All the praise to Pharo it actually allows
Maybe this happened with Squeak version 3.7?
http://wiki.squeak.org/squeak/1871
--Hannes
On 10/17/18, Richard O'Keefe wrote:
> There is an elephant in the room. Historically and in Smalltalks such as
> GNU Smalltalk, Smalltalk/X, my Smalltalk->C system, VisualAge Smalltalk,
> and VisualWOrks,
> On 17 Oct 2018, at 13:07, Richard O'Keefe wrote:
>
> There is an elephant in the room. Historically and in Smalltalks such as
> GNU Smalltalk, Smalltalk/X, my Smalltalk->C system, VisualAge Smalltalk,
> and VisualWOrks, a Date is *not* a TimeSpan and is *not* associated with
> a time zone
Hi Peter,
Have a look at:
http://smalltalkhub.com/#!/~zeroflag/Chain
As an alternative you may try the Specification Pattern
http://smalltalkhub.com/#!/~MassimoNocentini/SpecificationPattern
Cheers,
Hernán
El mié., 17 oct. 2018 a las 4:14, Peter Uhnak () escribió:
>
> Hi,
>
> is there
There is an elephant in the room. Historically and in Smalltalks such as
GNU Smalltalk, Smalltalk/X, my Smalltalk->C system, VisualAge Smalltalk,
and VisualWOrks, a Date is *not* a TimeSpan and is *not* associated with
a time zone or a zone offset. It's generally a direct subclass of
Magnitude.
Le mer. 17 oct. 2018 à 12:39, Dimitris Chloupis
a écrit :
>
> About your last part on platforms, I will be providing a way to inline C code
> so one can you use C macros to detect the platform and generate code
> accordingly. Or this could happen via a pragma too, it should not be an
> issue.
yes exactly There is for Unix (which includes macos and linux)
UnixDynamicLoader >>loadLibrary: filename flag: flag
^ self ffiCall: #(void *dlopen(const char *filename, int flag))
while for windows is
WindowsDynamicLoader>>loadLibrary: lpFileName
^ self ffiCall: #(void
About your last part on platforms, I will be providing a way to inline C
code so one can you use C macros to detect the platform and generate code
accordingly. Or this could happen via a pragma too, it should not be an
issue. This also a reason why I previously talked about an "in place"
Afaik, dlopen(3), which I presume UFFI uses internally to load (shared)
libraries on demand (I cannot imagine anything else), looks in
LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on macOS), not in PATH.
So let's focus on one of my question again, reworded here:
What is the strategy that UFFI
Hello Allistair
I have used Slang only once and it was generating code that was indeed
readbale but my aim is for more finer control over the output. Lets say I
want import a specific C header file or I want a string to map to custom C
type I created etc. So yes Slang is by no mean a bad tool at
yeah I apologise for the wrong example , LibC utilises the
enviroment/system variables.
Generally speaking all OSes have a PATH variable that defines the places
where common libraries and tools are to be found. If you are on windows you
can type in the command prompt , "PATH", in Linux and MacOS
Hi Dimitris,
As someone currently learning to use Slang (i.e. not an expert), I've
added my 2c below...
On Wed, 17 Oct 2018 at 11:06, Dimitris Chloupis wrote:
>
> Thierry you have done it !!! you just gave a very easy solution to my
> problems.
>
> Yeap Slang is quite close to what I am
Hi Dimitris,
thanks for the long explanation.
As you can see from my example, I build the library with the
-undefined dynamic_lookup
flag to clang, so this should be compatible with your (3) option if I
understand you correctly. Compiling/linking this way should allow the
use of dlopen(3)
I advice first of all the use of CMake , you can thank me later.
CMake if you are not aware is the standard build system for C/C++ , it
makes it super easy to build and compile projects so you dont have to do
what you are doing, call the compiler and pass the inifite amount of
compiler flags that
Thierry you have done it !!! you just gave a very easy solution to my
problems.
Yeap Slang is quite close to what I am thinking, unfortunately Clement told
me to stay away from it because the code is ugly and specially used for VM
only. If I remember also correctly it does not generate readable C
Hello,
I've made some attempts to use the Pharo FFI. I've gone through the
documentation [1] and tried some examples.
While the documentation is quite clear about using external libraries
from Pharo, it lacks details on how to build own libraries to be used
from Pharo.
Specifically, I'm
Le mer. 17 oct. 2018 à 08:44, Dimitris Chloupis
a écrit :
>
> Those are interesting languages and probably better ideas than what I am
> thinking. However they are not what I am talking about.
>
> The language I am making is called "Magnatar"
>
> Magnatar is not Smalltalk, but it is a Smalltalk
Hi,
is there some library that will allow me to chain select:/collect:/... via
cascade?
E.g.
#(12 7 'a' nil #(0)) query reject: #isNil; select: #isNumber; collect:
#squared; select: #even?
The point is to not have to write billion parentheses when building a more
complex query.
I imagine this
Those are interesting languages and probably better ideas than what I am
thinking. However they are not what I am talking about.
The language I am making is called "Magnatar"
Magnatar is not Smalltalk, but it is a Smalltalk trojan horse.
My main goals are
1) Create 100% readable C code, code
30 matches
Mail list logo
