Re: [E-devel] [support.osuosl.org #29680] enlightenment5.osuosl.oob fan failure
On Tue, 20 Feb 2018 16:19:17 -0800 "Jonathan Frederick via RT" said: replying to cedric's alternate maill as his efl.so one was running off e5 which just pooped its raid10 array yesterday. cedric's in CA so he's closest to arrange this. > On Mon Feb 12 16:11:28 2018, doublej472 wrote: > > On Sun Jan 14 16:08:42 2018, bertr...@jacquin.bzh wrote: > > > Hi, > > > > > > > >> Cedric, can we order a set of new fan to replace the existing ? > > I won't > > > > >> be surprised they have been damaged with time. > > > > > > > > Sure. Do you have a reference or better a link to buy it of Amazon > > ? > > > > > > It's kind of hard to get the exact model from SuperMicro specs > > > > > > https://www.supermicro.com/products/motherboard/Xeon/C600/X9DBL- > > 3F.cfm > > > > > > I've contacted the sales from supermicro in a separate thread in > > order > > > to progress in this. > > > > > > Cheers > > > > > > > Ping! Any update? I haven't checked on the server recently > > > > -- > > Jonathan Frederick > > Student Systems Engineer > > Oregon State University | Open Source Lab > > Ping! > > -- > Jonathan Frederick > Student Systems Engineer > Oregon State University | Open Source Lab > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] test e-devel list
On Tue, 20 Feb 2018 12:11:45 +0100 Stefan Schmidt said: > Hello. > > > On 02/20/2018 12:10 PM, Stefan Schmidt wrote: > > Hello. > > > > > > Its the second time since last week that I miss a mail being delivered to > > e-devel. > > > > Last time I got at least an mailer message but this time I got nothing. > > Checking if that still is the case now. > > > > > > Interesting, this one arrived in an instant. sf.net were doing some migration end of last week. i suspect it still wasn't resolved yet over the weekend until maybe about now... -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [support.osuosl.org #29680] enlightenment5.osuosl.oob fan failure
On Tue, 20 Feb 2018 16:19:17 -0800 "Jonathan Frederick via RT" said: replying to cedric's alternate maill as his efl.so one was running off e5 which just pooped its raid10 array yesterday. cedric's in CA so he's closest to arrange this. > On Mon Feb 12 16:11:28 2018, doublej472 wrote: > > On Sun Jan 14 16:08:42 2018, bertr...@jacquin.bzh wrote: > > > Hi, > > > > > > > >> Cedric, can we order a set of new fan to replace the existing ? > > I won't > > > > >> be surprised they have been damaged with time. > > > > > > > > Sure. Do you have a reference or better a link to buy it of Amazon > > ? > > > > > > It's kind of hard to get the exact model from SuperMicro specs > > > > > > https://www.supermicro.com/products/motherboard/Xeon/C600/X9DBL- > > 3F.cfm > > > > > > I've contacted the sales from supermicro in a separate thread in > > order > > > to progress in this. > > > > > > Cheers > > > > > > > Ping! Any update? I haven't checked on the server recently > > > > -- > > Jonathan Frederick > > Student Systems Engineer > > Oregon State University | Open Source Lab > > Ping! > > -- > Jonathan Frederick > Student Systems Engineer > Oregon State University | Open Source Lab > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] UnifiedAPI Namespace definition proposal
On Sun, 18 Feb 2018 10:28:54 +0100 Davide Andreoli said: hey dave. i had this marked... :) > Hi all, > > I'm working again on autogenerated python bindings for efl UnifiedAPI but > I'm quite blocked by the lack of namespace definitions in eo/eolian. a read of the below... why can't you just have a single Efl namespace? I'm not sure I get the need for complex namespaces here... you have classes... and they can all be within the EFl namespace... :) any reason you can't do this? doesn't this simplify things? > This is a noproblem in C and any other language without proper namespacing, > but for the langs that provide namespaces (like python and many others) > this need to be defined in some way. > > First of all we need to define what a namespace is, and define some rules > for them. Then we should implement something in Eolian so that every > different bindings can be generated with the same namespace hierarchy. > > Currently I'm assuming that the namespace of an object (class or typedecl) > is its full name without the last part, fe the Efl.Canvas.Object live in > the Efl.Canvas namespace. Is this correct? is this what we want? Well we are pretty much using a tree structure for the efl classes, so i think this applies, but something in the Efl.Canvas namespace could inherit a class or interface from Efl.Elephant does that bother you? it's still obj.methodname() or similar... the namespace is only relevant when creating the object ... i.e. its class and ... can't that just be EFl.something_something_blah ? educate me... i know nothing about python here so i doubt i can offer a lot of advice here... (which is why i haven't jumped in to answer this). > As for the rules we should define some, I have two on my mind atm: > 1. (definition) The namespace of an object is it's full name without the > last part (mybe lowercased?) > 2. A namespace cannot have the same name of another eo object (classes, > enums, typedefs, aliases, etc) this is going to be hard to enforce unless eolian enforces it and tells us there is a conflict... :) > The #2 is mandatory in python. I can workaround this in my generator by > lowercasing the namespaces (fe: efl.canvas.Object), but seems to me that > having 2 different things (a class and a namespace) with the same name is > confusing for everyone and probably will not work for languages/systems > without a case-sensitive filesystem (thinking about windoz here) > > > To better understand what I'm speaking about please give a look at: > http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:start > http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:namespaces > > Those pages are automatically generated, are NOT python related, and should > serve as a reference for the UnifiedAPI work in progess, they provide a > clean view of the current state of our new API. > > > waiting for comments and ideas > davemds > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] compiling efl with wayland support
To be precise, the README.wayland file says "This Readme does not address the dependencies needed to enable Wayland in EFL. If you require any information for that..." meaning that the link is only a reference for dependency information. The README.wayland file does accurately cover all necessary configuration options for EFL. On Thu, Feb 22, 2018 at 2:47 PM Antonio Palladini wrote: > On Thu, 22 Feb 2018 18:32:56 + Mike Blumenkrantz > wrote: > > > > It seems that this documentis tremendously out of date. If you are > looking > > to run Enlightenment as a Wayland compositor, I would recommend following > > the instructions here > > https://git.enlightenment.org/core/enlightenment.git/tree/README.wayland > > indeed, but this says, for compiling efl go to > https://phab.enlightenment.org/w/wayland/ > > Kind regards > > palla > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] compiling efl with wayland support
On Thu, 22 Feb 2018 18:32:56 + Mike Blumenkrantz wrote: > > It seems that this documentis tremendously out of date. If you are looking > to run Enlightenment as a Wayland compositor, I would recommend following > the instructions here > https://git.enlightenment.org/core/enlightenment.git/tree/README.wayland indeed, but this says, for compiling efl go to https://phab.enlightenment.org/w/wayland/ Kind regards palla -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] UnifiedAPI Namespace definition proposal
It seems there is some confusion both in this mail and in the community about how the interfaces API works, partly due to how .eo files work and the current syntax that is used. Some changes are in progress to make things more clear, and there will be more info on this soon. Regarding the points that you have raised, it's important to separate the concepts of "EFL API" and "EFL API implementation". The former is the specification in the eo files while the latter is the code which is created using an eolian generator for a given language. This is a significant detail because the EFL API does not vary (as there is only one instance of it) while the EFL API implementation is simply the interpretation of the EFL API within the confines of the implementation language. This means that, for example, the Python implementation of the EFL API is "whatever works best for Python users" and not "the exact copying of the EFL API". The key point in this is to create a language-based implementation of the EFL API which can correlate to the documentation for EFL API functionality such that users of the language are able to effectively develop applications based on the docs. As an example of this, there is an EFL API namespace "Efl.Canvas.Animation". In C, however, this is implemented with the API namespace efl_animation, omitting "canvas" entirely. Other languages may choose to retain "canvas" in their implementation if it is necessary or relevant, but this is not a requirement. On Thu, Feb 22, 2018 at 8:10 AM Davide Andreoli wrote: > Hi all, > > I'm working again on autogenerated python bindings for efl UnifiedAPI but > I'm quite blocked by the lack of namespace definitions in eo/eolian. > > This is a noproblem in C and any other language without proper namespacing, > but for the langs that provide namespaces (like python and many others) > this need to be defined in some way. > > First of all we need to define what a namespace is, and define some rules > for them. Then we should implement something in Eolian so that every > different bindings can be generated with the same namespace hierarchy. > > Currently I'm assuming that the namespace of an object (class or typedecl) > is its full name without the last part, fe the Efl.Canvas.Object live in > the Efl.Canvas namespace. Is this correct? is this what we want? > > As for the rules we should define some, I have two on my mind atm: > 1. (definition) The namespace of an object is it's full name without the > last part (mybe lowercased?) > 2. A namespace cannot have the same name of another eo object (classes, > enums, typedefs, aliases, etc) > > The #2 is mandatory in python. I can workaround this in my generator by > lowercasing the namespaces (fe: efl.canvas.Object), but seems to me that > having 2 different things (a class and a namespace) with the same name is > confusing for everyone and probably will not work for languages/systems > without a case-sensitive filesystem (thinking about windoz here) > > > To better understand what I'm speaking about please give a look at: > http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:start > http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:namespaces > > Those pages are automatically generated, are NOT python related, and should > serve as a reference for the UnifiedAPI work in progess, they provide a > clean view of the current state of our new API. > > > waiting for comments and ideas > davemds > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] compiling efl with wayland support
It seems that this document is tremendously out of date. If you are looking to run Enlightenment as a Wayland compositor, I would recommend following the instructions here https://git.enlightenment.org/core/enlightenment.git/tree/README.wayland On Thu, Feb 22, 2018 at 1:16 PM Antonio Palladini wrote: > > Hello Devs, > > I have tried to compile efl with wayland support but got the following > error ; > > CC > lib/ecore_wayland/lib_ecore_wayland_libecore_la-ecore_wl.lo > In file included from lib/ecore_wayland/ecore_wl_private.h:10:0, from > lib/ecore_wayland/ecore_wl.c:6: > lib/ecore_wayland/Ecore_Wayland.h:30:3: Warnung: #warning The > Ecore_Wayland library has been deprecated. Please use the Ecore_Wl2 > library [-Wcpp] # warning The Ecore_Wayland library has been > deprecated. Please use the Ecore_Wl2 library > > I am following the instructions on > https://phab.enlightenment.org/w/wayland > > I am sure there is a switch i have to use, but can not find it. > > Someone please point me to the right direction. > > > kind regards > > palla > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] compiling efl with wayland support
Hello Devs, I have tried to compile efl with wayland support but got the following error ; CC lib/ecore_wayland/lib_ecore_wayland_libecore_la-ecore_wl.lo In file included from lib/ecore_wayland/ecore_wl_private.h:10:0, from lib/ecore_wayland/ecore_wl.c:6: lib/ecore_wayland/Ecore_Wayland.h:30:3: Warnung: #warning The Ecore_Wayland library has been deprecated. Please use the Ecore_Wl2 library [-Wcpp] # warning The Ecore_Wayland library has been deprecated. Please use the Ecore_Wl2 library I am following the instructions on https://phab.enlightenment.org/w/wayland I am sure there is a switch i have to use, but can not find it. Someone please point me to the right direction. kind regards palla -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] UnifiedAPI Namespace definition proposal
Hi all, I'm working again on autogenerated python bindings for efl UnifiedAPI but I'm quite blocked by the lack of namespace definitions in eo/eolian. This is a noproblem in C and any other language without proper namespacing, but for the langs that provide namespaces (like python and many others) this need to be defined in some way. First of all we need to define what a namespace is, and define some rules for them. Then we should implement something in Eolian so that every different bindings can be generated with the same namespace hierarchy. Currently I'm assuming that the namespace of an object (class or typedecl) is its full name without the last part, fe the Efl.Canvas.Object live in the Efl.Canvas namespace. Is this correct? is this what we want? As for the rules we should define some, I have two on my mind atm: 1. (definition) The namespace of an object is it's full name without the last part (mybe lowercased?) 2. A namespace cannot have the same name of another eo object (classes, enums, typedefs, aliases, etc) The #2 is mandatory in python. I can workaround this in my generator by lowercasing the namespaces (fe: efl.canvas.Object), but seems to me that having 2 different things (a class and a namespace) with the same name is confusing for everyone and probably will not work for languages/systems without a case-sensitive filesystem (thinking about windoz here) To better understand what I'm speaking about please give a look at: http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:start http://www.gurumeditation.it/dokuwiki/doku.php?id=develop:api:namespaces Those pages are automatically generated, are NOT python related, and should serve as a reference for the UnifiedAPI work in progess, they provide a clean view of the current state of our new API. waiting for comments and ideas davemds -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 03/03: lets delete efl_vpath
As i said on irc, its copied over from rasters efl_vpath
implementations. Maybe he can answer on why there are aborts.
As far as i remember, the reasoning was that a error message does not
make much sense here, since those errors are critical, and cannot be
recovered from in a sane manner, so every runtime after that will NOT be
stable.
Further more, the aborts are in a call that is called in the beginning,
at startup, so you will not get a random abort somewhere in the runtime,
rather your app will not come up :)
Greetings,
bu5hm4n
On 02/22/2018 10:53 AM, Vincent Torri wrote:
maybe it's just me but i really dislike an abort() in eina (and
generally in any library)
if there is an error, it should fail nicely
vincent
On Thu, Feb 22, 2018 at 10:40 AM, Marcel Hollerbach wrote:
Hello,
i sadly discovered on a system that autotools does not understand that there
is a new eina header.
You might run into issues where eina_vpath.h is not installed correctly on
your system, to fix this just run ./configure again, then it will work.
Greetings,
bu5hm4n
On 02/22/2018 09:35 AM, Marcel Hollerbach wrote:
bu5hm4n pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=8c7ba8c3a31ec671ccd6d7d30682dbd631d69a62
commit 8c7ba8c3a31ec671ccd6d7d30682dbd631d69a62
Author: Marcel Hollerbach
Date: Sun Feb 18 21:58:57 2018 +0100
lets delete efl_vpath
Its not used anymore.
ref T5314
---
src/Makefile_Efl.am | 9 -
src/lib/efl/Efl.h | 6 -
src/lib/efl/interfaces/efl_interfaces_main.c | 2 -
src/lib/efl/interfaces/efl_vpath.eo | 31 --
src/lib/efl/interfaces/efl_vpath_core.c | 436
--
src/lib/efl/interfaces/efl_vpath_core.eo | 33 --
src/lib/efl/interfaces/efl_vpath_file.c | 74 -
src/lib/efl/interfaces/efl_vpath_file.eo | 55
src/lib/efl/interfaces/efl_vpath_file_core.c | 66
src/lib/efl/interfaces/efl_vpath_file_core.eo | 14 -
src/lib/efl/interfaces/efl_vpath_manager.c| 88 --
src/lib/efl/interfaces/efl_vpath_manager.eo | 30 --
12 files changed, 844 deletions(-)
diff --git a/src/Makefile_Efl.am b/src/Makefile_Efl.am
index 01b98ddfde..f98f554362 100644
--- a/src/Makefile_Efl.am
+++ b/src/Makefile_Efl.am
@@ -54,11 +54,6 @@ efl_eolian_files = \
lib/efl/interfaces/efl_pack_layout.eo \
lib/efl/interfaces/efl_pack_linear.eo \
lib/efl/interfaces/efl_pack_table.eo \
- lib/efl/interfaces/efl_vpath.eo \
- lib/efl/interfaces/efl_vpath_manager.eo \
- lib/efl/interfaces/efl_vpath_file.eo \
- lib/efl/interfaces/efl_vpath_core.eo \
- lib/efl/interfaces/efl_vpath_file_core.eo \
lib/efl/interfaces/efl_ui_base.eo \
lib/efl/interfaces/efl_ui_direction.eo \
lib/efl/interfaces/efl_ui_drag.eo \
@@ -122,10 +117,6 @@ lib/efl/interfaces/efl_interfaces_main.c \
lib/efl/interfaces/efl_model_common.c \
lib/efl/interfaces/efl_gfx_path.c \
lib/efl/interfaces/efl_gfx_shape.c \
-lib/efl/interfaces/efl_vpath_file.c \
-lib/efl/interfaces/efl_vpath_manager.c \
-lib/efl/interfaces/efl_vpath_core.c \
-lib/efl/interfaces/efl_vpath_file_core.c \
lib/efl/interfaces/efl_input_device.c \
lib/efl/interfaces/efl_io_closer.c \
lib/efl/interfaces/efl_io_positioner.c \
diff --git a/src/lib/efl/Efl.h b/src/lib/efl/Efl.h
index ed7405ced8..2399c9c30b 100644
--- a/src/lib/efl/Efl.h
+++ b/src/lib/efl/Efl.h
@@ -62,12 +62,6 @@ typedef struct _Efl_Text_Annotate_Annotation
Efl_Text_Annotate_Annotation;
#include
-#include "interfaces/efl_vpath_file.eo.h"
-#include "interfaces/efl_vpath.eo.h"
-#include "interfaces/efl_vpath_core.eo.h"
-#include "interfaces/efl_vpath_manager.eo.h"
-#include "interfaces/efl_vpath_file_core.eo.h"
-
/* Data types */
#include "interfaces/efl_gfx_types.eot.h"
#include "interfaces/efl_ui_types.eot.h"
diff --git a/src/lib/efl/interfaces/efl_interfaces_main.c
b/src/lib/efl/interfaces/efl_interfaces_main.c
index d9b87634a6..cb1738e52b 100644
--- a/src/lib/efl/interfaces/efl_interfaces_main.c
+++ b/src/lib/efl/interfaces/efl_interfaces_main.c
@@ -46,8 +46,6 @@
#include "interfaces/efl_canvas.eo.c"
#include "interfaces/efl_canvas_pointer.eo.c"
-#include "interfaces/efl_vpath.eo.c"
-
#include "interfaces/efl_screen.eo.c"
/* Packing & containers */
diff --git a/src/lib/efl/interfaces/efl_vpath.eo
b/src/lib/efl/interfaces/efl_vpath.eo
deleted file mode 100644
index ca97f1b090..00
--- a/src/lib/efl/interfaces/efl_vpath.eo
+++ /dev/null
@@ -1,31 +0,0 @@
-interface Efl.Vpath
-{
- [[ VPath is the EFL "Virtual Path" system that maps paths and
downloads
-
- You can provide virtual paths common in unix shells like:
- "~/file.jpg"
- "~username/file.png"
- And also other extended paths like:
- "(:cache:)/file.png"
- "(:videos:)/file.mp4"
-
Re: [E-devel] [EGIT] [core/efl] master 03/03: lets delete efl_vpath
maybe it's just me but i really dislike an abort() in eina (and
generally in any library)
if there is an error, it should fail nicely
vincent
On Thu, Feb 22, 2018 at 10:40 AM, Marcel Hollerbach wrote:
> Hello,
>
> i sadly discovered on a system that autotools does not understand that there
> is a new eina header.
> You might run into issues where eina_vpath.h is not installed correctly on
> your system, to fix this just run ./configure again, then it will work.
>
> Greetings,
>bu5hm4n
>
>
> On 02/22/2018 09:35 AM, Marcel Hollerbach wrote:
>>
>> bu5hm4n pushed a commit to branch master.
>>
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=8c7ba8c3a31ec671ccd6d7d30682dbd631d69a62
>>
>> commit 8c7ba8c3a31ec671ccd6d7d30682dbd631d69a62
>> Author: Marcel Hollerbach
>> Date: Sun Feb 18 21:58:57 2018 +0100
>>
>> lets delete efl_vpath
>> Its not used anymore.
>> ref T5314
>> ---
>> src/Makefile_Efl.am | 9 -
>> src/lib/efl/Efl.h | 6 -
>> src/lib/efl/interfaces/efl_interfaces_main.c | 2 -
>> src/lib/efl/interfaces/efl_vpath.eo | 31 --
>> src/lib/efl/interfaces/efl_vpath_core.c | 436
>> --
>> src/lib/efl/interfaces/efl_vpath_core.eo | 33 --
>> src/lib/efl/interfaces/efl_vpath_file.c | 74 -
>> src/lib/efl/interfaces/efl_vpath_file.eo | 55
>> src/lib/efl/interfaces/efl_vpath_file_core.c | 66
>> src/lib/efl/interfaces/efl_vpath_file_core.eo | 14 -
>> src/lib/efl/interfaces/efl_vpath_manager.c| 88 --
>> src/lib/efl/interfaces/efl_vpath_manager.eo | 30 --
>> 12 files changed, 844 deletions(-)
>>
>> diff --git a/src/Makefile_Efl.am b/src/Makefile_Efl.am
>> index 01b98ddfde..f98f554362 100644
>> --- a/src/Makefile_Efl.am
>> +++ b/src/Makefile_Efl.am
>> @@ -54,11 +54,6 @@ efl_eolian_files = \
>> lib/efl/interfaces/efl_pack_layout.eo \
>> lib/efl/interfaces/efl_pack_linear.eo \
>> lib/efl/interfaces/efl_pack_table.eo \
>> - lib/efl/interfaces/efl_vpath.eo \
>> - lib/efl/interfaces/efl_vpath_manager.eo \
>> - lib/efl/interfaces/efl_vpath_file.eo \
>> - lib/efl/interfaces/efl_vpath_core.eo \
>> - lib/efl/interfaces/efl_vpath_file_core.eo \
>> lib/efl/interfaces/efl_ui_base.eo \
>> lib/efl/interfaces/efl_ui_direction.eo \
>> lib/efl/interfaces/efl_ui_drag.eo \
>> @@ -122,10 +117,6 @@ lib/efl/interfaces/efl_interfaces_main.c \
>> lib/efl/interfaces/efl_model_common.c \
>> lib/efl/interfaces/efl_gfx_path.c \
>> lib/efl/interfaces/efl_gfx_shape.c \
>> -lib/efl/interfaces/efl_vpath_file.c \
>> -lib/efl/interfaces/efl_vpath_manager.c \
>> -lib/efl/interfaces/efl_vpath_core.c \
>> -lib/efl/interfaces/efl_vpath_file_core.c \
>> lib/efl/interfaces/efl_input_device.c \
>> lib/efl/interfaces/efl_io_closer.c \
>> lib/efl/interfaces/efl_io_positioner.c \
>> diff --git a/src/lib/efl/Efl.h b/src/lib/efl/Efl.h
>> index ed7405ced8..2399c9c30b 100644
>> --- a/src/lib/efl/Efl.h
>> +++ b/src/lib/efl/Efl.h
>> @@ -62,12 +62,6 @@ typedef struct _Efl_Text_Annotate_Annotation
>> Efl_Text_Annotate_Annotation;
>> #include
>> -#include "interfaces/efl_vpath_file.eo.h"
>> -#include "interfaces/efl_vpath.eo.h"
>> -#include "interfaces/efl_vpath_core.eo.h"
>> -#include "interfaces/efl_vpath_manager.eo.h"
>> -#include "interfaces/efl_vpath_file_core.eo.h"
>> -
>> /* Data types */
>> #include "interfaces/efl_gfx_types.eot.h"
>> #include "interfaces/efl_ui_types.eot.h"
>> diff --git a/src/lib/efl/interfaces/efl_interfaces_main.c
>> b/src/lib/efl/interfaces/efl_interfaces_main.c
>> index d9b87634a6..cb1738e52b 100644
>> --- a/src/lib/efl/interfaces/efl_interfaces_main.c
>> +++ b/src/lib/efl/interfaces/efl_interfaces_main.c
>> @@ -46,8 +46,6 @@
>> #include "interfaces/efl_canvas.eo.c"
>> #include "interfaces/efl_canvas_pointer.eo.c"
>> -#include "interfaces/efl_vpath.eo.c"
>> -
>> #include "interfaces/efl_screen.eo.c"
>> /* Packing & containers */
>> diff --git a/src/lib/efl/interfaces/efl_vpath.eo
>> b/src/lib/efl/interfaces/efl_vpath.eo
>> deleted file mode 100644
>> index ca97f1b090..00
>> --- a/src/lib/efl/interfaces/efl_vpath.eo
>> +++ /dev/null
>> @@ -1,31 +0,0 @@
>> -interface Efl.Vpath
>> -{
>> - [[ VPath is the EFL "Virtual Path" system that maps paths and
>> downloads
>> -
>> - You can provide virtual paths common in unix shells like:
>> - "~/file.jpg"
>> - "~username/file.png"
>> - And also other extended paths like:
>> - "(:cache:)/file.png"
>> - "(:videos:)/file.mp4"
>> - ...
>> - And in future:
>> - "file:///blah.jpg"
>> - "http://blah.com/file.jpg";
>> - "https://blahblah.com/file.jpg";
>> - "ssh://blahblah.com:~/file.jpg"
>> - ...
>> -
>> - @since 1.18
>> - ]]
>> - eo_prefix: efl_vpath;
>> - methods {
>> - fetch {
>> - [[
Re: [E-devel] [EGIT] [core/efl] master 03/03: lets delete efl_vpath
Hello,
i sadly discovered on a system that autotools does not understand that
there is a new eina header.
You might run into issues where eina_vpath.h is not installed correctly
on your system, to fix this just run ./configure again, then it will work.
Greetings,
bu5hm4n
On 02/22/2018 09:35 AM, Marcel Hollerbach wrote:
bu5hm4n pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=8c7ba8c3a31ec671ccd6d7d30682dbd631d69a62
commit 8c7ba8c3a31ec671ccd6d7d30682dbd631d69a62
Author: Marcel Hollerbach
Date: Sun Feb 18 21:58:57 2018 +0100
lets delete efl_vpath
Its not used anymore.
ref T5314
---
src/Makefile_Efl.am | 9 -
src/lib/efl/Efl.h | 6 -
src/lib/efl/interfaces/efl_interfaces_main.c | 2 -
src/lib/efl/interfaces/efl_vpath.eo | 31 --
src/lib/efl/interfaces/efl_vpath_core.c | 436 --
src/lib/efl/interfaces/efl_vpath_core.eo | 33 --
src/lib/efl/interfaces/efl_vpath_file.c | 74 -
src/lib/efl/interfaces/efl_vpath_file.eo | 55
src/lib/efl/interfaces/efl_vpath_file_core.c | 66
src/lib/efl/interfaces/efl_vpath_file_core.eo | 14 -
src/lib/efl/interfaces/efl_vpath_manager.c| 88 --
src/lib/efl/interfaces/efl_vpath_manager.eo | 30 --
12 files changed, 844 deletions(-)
diff --git a/src/Makefile_Efl.am b/src/Makefile_Efl.am
index 01b98ddfde..f98f554362 100644
--- a/src/Makefile_Efl.am
+++ b/src/Makefile_Efl.am
@@ -54,11 +54,6 @@ efl_eolian_files = \
lib/efl/interfaces/efl_pack_layout.eo \
lib/efl/interfaces/efl_pack_linear.eo \
lib/efl/interfaces/efl_pack_table.eo \
- lib/efl/interfaces/efl_vpath.eo \
- lib/efl/interfaces/efl_vpath_manager.eo \
- lib/efl/interfaces/efl_vpath_file.eo \
- lib/efl/interfaces/efl_vpath_core.eo \
- lib/efl/interfaces/efl_vpath_file_core.eo \
lib/efl/interfaces/efl_ui_base.eo \
lib/efl/interfaces/efl_ui_direction.eo \
lib/efl/interfaces/efl_ui_drag.eo \
@@ -122,10 +117,6 @@ lib/efl/interfaces/efl_interfaces_main.c \
lib/efl/interfaces/efl_model_common.c \
lib/efl/interfaces/efl_gfx_path.c \
lib/efl/interfaces/efl_gfx_shape.c \
-lib/efl/interfaces/efl_vpath_file.c \
-lib/efl/interfaces/efl_vpath_manager.c \
-lib/efl/interfaces/efl_vpath_core.c \
-lib/efl/interfaces/efl_vpath_file_core.c \
lib/efl/interfaces/efl_input_device.c \
lib/efl/interfaces/efl_io_closer.c \
lib/efl/interfaces/efl_io_positioner.c \
diff --git a/src/lib/efl/Efl.h b/src/lib/efl/Efl.h
index ed7405ced8..2399c9c30b 100644
--- a/src/lib/efl/Efl.h
+++ b/src/lib/efl/Efl.h
@@ -62,12 +62,6 @@ typedef struct _Efl_Text_Annotate_Annotation
Efl_Text_Annotate_Annotation;
#include
-#include "interfaces/efl_vpath_file.eo.h"
-#include "interfaces/efl_vpath.eo.h"
-#include "interfaces/efl_vpath_core.eo.h"
-#include "interfaces/efl_vpath_manager.eo.h"
-#include "interfaces/efl_vpath_file_core.eo.h"
-
/* Data types */
#include "interfaces/efl_gfx_types.eot.h"
#include "interfaces/efl_ui_types.eot.h"
diff --git a/src/lib/efl/interfaces/efl_interfaces_main.c
b/src/lib/efl/interfaces/efl_interfaces_main.c
index d9b87634a6..cb1738e52b 100644
--- a/src/lib/efl/interfaces/efl_interfaces_main.c
+++ b/src/lib/efl/interfaces/efl_interfaces_main.c
@@ -46,8 +46,6 @@
#include "interfaces/efl_canvas.eo.c"
#include "interfaces/efl_canvas_pointer.eo.c"
-#include "interfaces/efl_vpath.eo.c"
-
#include "interfaces/efl_screen.eo.c"
/* Packing & containers */
diff --git a/src/lib/efl/interfaces/efl_vpath.eo
b/src/lib/efl/interfaces/efl_vpath.eo
deleted file mode 100644
index ca97f1b090..00
--- a/src/lib/efl/interfaces/efl_vpath.eo
+++ /dev/null
@@ -1,31 +0,0 @@
-interface Efl.Vpath
-{
- [[ VPath is the EFL "Virtual Path" system that maps paths and downloads
-
- You can provide virtual paths common in unix shells like:
- "~/file.jpg"
- "~username/file.png"
- And also other extended paths like:
- "(:cache:)/file.png"
- "(:videos:)/file.mp4"
- ...
- And in future:
- "file:///blah.jpg"
- "http://blah.com/file.jpg";
- "https://blahblah.com/file.jpg";
- "ssh://blahblah.com:~/file.jpg"
- ...
-
- @since 1.18
- ]]
- eo_prefix: efl_vpath;
- methods {
- fetch {
- [[ Fetch a new Vpath File object from the Vpath system ]]
- params {
-path: string; [[ The input virtual file path to fetch ]]
- }
- return: Efl.Vpath.File @owned; [[ An object representing the file ]]
- }
- }
-}
diff --git a/src/lib/efl/interfaces/efl_vpath_core.c
b/src/lib/efl/interfaces/efl_vpath_core.c
deleted file mode 100644
index d6b136374d..00
--- a/src/lib/efl/interfaces/efl_vpath_core.c
+++ /dev/null
@@ -1,436 +0,0 @@
-#include "config.h"
-#include "Efl.h"
-
-#ifdef HAVE_GETPWENT
-# in
